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ABSTRACT 

Relational  programming  is  a  methodology  which  combines 
the  advantages  o-f  ^^untional  programming  with  the  relatively 
simple  laws  which  govern  relations.  The  goal  is  to  give  the 
programmer  an  environment  which  allows  a  higher  level  o-f 
programming  abstraction  than  currently  exists,  an  easier 
approach  to  proving  programs  correct,  and  a  language  which 
can  support  new  parallel  architectures.  In  this  report,  the 
design  and  implementation  o-f  a  prototype  interactive  inter- 
preter -for  a  relational  programming  language  is  presented. 
The  reasoning  behind  the  decision  to  use  LISP  as  the 
implementation  language  is  presented  followed  by  an  in  depth 
discussion  o-f  the  design  issues  involved  and  the  implementa- 
tion decisions  made.  How  to  use  the  interpreter  and  future 
research  topics  3.rE;  discussed.  Also  several  appendices  s.rs 
provided  which  include  the  grammar,  the  relational  operators 
implemented,  and  the  documented  LISP  code. 
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I  -  iNlRQDycii ON 

Relational  programming  is  a  programming  style  which  uses 
the  relation  as  the  basic  structure  -For  all  programming. 
This  innovative  methodology  may  be  a  sound  approach  to 
meeting  the  -future  needs  o-f  the  computer  science  community. 
Because  entire  relations  are  manipulated  instead  o-f 
individual  data  elements,  relational  programming  may  serve 
as  the  basis  -for  an  e-f-ficient,  modern  machine  architecture 
which  will  overcome  the  limitations  and  low  level  word— at-a— 
time  processing  of  the  von  Neumann  type  computers. 

A  relational  programming  language  is  a  higher  level 
language  than  conventional  languages  such  as  Fortran, 
Pascal,  and  Algol.  These  languages  are  sequential  in  nature 
and  involve  the  programmer  in  many  low  level  programming 
decisions  such  as  keeping  track  o-f  counters  or  indices  to 
array  structures.  This  means  that  the  programmer  must  worry 
about  how  to  manipulate  individual  members  o-f  an  array  to 
achieve  the  desired  result  instead  o-f  being  able  to  deal 
with  the  array  structure  as  a  whole.  Relational  programming 
frees  the  programmer  from  these  types  of  decisions,  allowing 
him  to  work  at  a  higher  level  of  abstraction,  concentrating 
more  on  WHAT  the  program  must  do,  but  not  details  of  HOW  it 
will  be  done.  Relational  programming  can  do  this  because 
data   and   programs  are    not  treated  differently.    Data   and 
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programs  e^re    equivalent  since  they  a.re    based  upon  a  .  common 
structure,  the  relation. 

The  relation  is  a  reasonable  and  -feasible  basis  -for  a 
programming  language  because  a  well  developed  theory  o-f 
relations  exists  and  the  laws  which  govern  relations  are 
relatively  simple.  A  similar  approach  to  relational 
programming,  which  has  been  an  active  a.rsai  o-f  research,  is 
-functional  programming.  Backus  described  in  his  Turing 
Award  paper  CRe-f.  11  a  -functional  language,  FP,  and  its 
advantages  in  meeting  -future  programming  needs.  As 
MacLennan  CRe-f.  211  has  stated  relational  programming 
subsumes  -functional  programming  because  every  -function  is  a 
relation.  There-fore  everything  that  can  be  done  in  a 
-functional  language  can  be  done  in  a  relational  programming 
language.  MacLennan  has  described  the  advantages  o-f 
relational  programming  and  demonstrated  its  potential  as  a 
powerful  high  level  language.  These  advantages  3.rs 
summarized  below: 

1.  Relational   programming  supports  abstract  higher  level 
progr ammi  ng . 

2.  Relational   programming   deals  with  a  single   kind   o-f 
entity,  the  relation,  and  uses  it  -for  all  purposes. 

3.  Relational   programming   more  directly   supports   non- 
linear data    structures  such  as  trees  and  graphs. 

4.  Programs  can  be  algebraically  derived  and  manipulated. 

5.  Relational    programming    can   more   easily    support 
utilization  o-f  associative   and  active  memories. 


This  research  will  serve  as  a  mechanism  to  demonstrate 
the  practicality  and  -Feasibility  o-F  a  relational  programming 
language  as  described  by  MacLennan  CRe-f.  23.  Therefore, 
■familiarity  with  his  report  is  necessary  to  better 
understand  the  -further  development  o-f  his  work  presented 
here. 

This  report  will  describe  the  development  and  design  o-f 
a  prototype  interactive  interpreter  -for  a  relational 
programming  language.  It  will  also  demonstrate  that  such  an 
interpreter  is  i mpl ementable  on  a  current  machine 
architecture,  although  it  would  probably  be  more  suitable  to 
a  newer  type  o-f  architecture. 

This  research  and  its  product,  an  interactive  Relational 
Programming  Language  (RPL)  interpreter,  will  serve  as  a 
kernel  and  impetus  -for  follow— on  work  with  relational 
programming  concepts.  It  is  hoped  that  the  issues  and 
decisions  made  in  this  implementation  will  provide  the 
answers  to  some  of  the  basic  questions,  and  identify  some 
critical  areas  for  future  research. 
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1 1 .   BACKGROUND 

The  von  Neumann  model  o-f  computation  has  been  dominant 
-For  the  last  30  years  and  has  remained  largely  unchanged 
even  though  significant  advances  in  both  so-ftware  and 
hardware  technology  have  taken  place.  Applications  continue 
to  become  more  complex  and  sophisticated,  requiring 
increasingly  more  power -ful  computer  systems.  To  date, 
extensions  o-F  conventional  so-ftware  systems  have  seemed  tc 
meet  the  demands.  However,  it  has  become  quite  clear  that  an 
alternative  to  the  von  Neumann  computer  organization  is 
needed. 

Programming  languages  were  originally  designed  -for  and 
have  supported  the  von  Neumann  machine  architecture.  But, 
as  technology  has  advanced,  the  von  Neumann  sequential  word— 
at— a— time  bottleneck  has  become  painfully  apparent.  Real 
world  applications  3.rs  not  sequential  in  nature  and  the 
conversion  o-f  concurrent  processes  to  operate  sequentially 
a-f-fects  efficiency  and  speed  of  computation. 

Hardware  research  has  acknowledged  that  a  fundamental 
limit  exists  on  the  performance  increases  which  can  be 
derived  from  advances  in  technology  alone.  VLSI  technology 
seems  to  be  naturally  suited  to  new  types  of  parallel 
architectures,  and  programming  language  design  is  following 
suit   with   the   development   of   higher   level   programming 
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languages  which  Sire  more  power-Ful  ,  abstract  and  easier  to 
prove  correct.  The  increasing  complexity  o-f  real  world 
applications  is  dictating  a  need  for  higher  levels  o-f 
abstraction  so  that  the  programmer  can  concentrate  on  the 
overall  solution  without  becoming  bogged  down  in  the 
details.  Relational  programming  is  one  possible  solution  to 
this  problem. 

Relational  programming  is  based  upon  the  use  o-f  a 
relational  calculus  which  can  model  almost  any  data 
structure.  There-fore,  the  high  level  relational  operators 
can  also  be  used  to  manipulate  entire  data  structures. 
MacLennan  has  presented  and  discussed  the  basis  tor  a 
relational  programming  language  in  references  2  and  3.  The 
operators  he  describes  Are  based  on  naive  set  theory  and 
operate  on  three  basic  objects:'  individuals,  binary 
relations  and  sets.  Individuals  Are  the  indivisible  data 
values  which  can  be  used  to  compute.  A  binary  relation  is 
some  property  which  relates  one  object  to  another.  For 
example,  the  less  than  (<)  relation  relates  all  pairs  of 
values,  ;;  and  y,  for  which  x  is  less  than  y.  Therefore  the 
pair  (3,4)  is  a  member  of  the  '<'  relation.  The  ' -^ ' 
relation  can  be  denoted  (K,y)-»-z,  which  means  that  it  takes  a 
pair  (x,y)  and  relates  it  to  its  sum  z.  In  general,  a 
relation  can  be  represented  by  the  notation,  xRy  where  x  and 
y  may  represent  any  objects. 


12 


A  set  is  any  grouping  of  individuals,  binary  relations 
and/or  other  sets.  '  Thus  there  is  no  restriction  on  what 
sets  or  relations  can  be  members  of  other  sets  and 
relations. 

With  these  basic  objects,  MacLennan  develops  and 
describes  the  operators  which  he  feels  would  be  useful  to 
the  relational  programmer,  and  demonstrates  the  potential 
advantages  of  a  programming  language  based  upon  a  relational 
calculus.  He  shows  that  relational  operators  can  be 
algebraically  manipulated  to  derive  other,  more  compieK 
operators.  This  ability  supports  the  premise  that 
relational  programs  would  be  easier  to  prove  correct.  It 
also  demonstrates  that  programs  can  operate  on  other 
programs  to  yield  relatively  strai ght— forward  solutions  to 
complex  problems.  High  level  abstraction  is  thus  supported, 
allowing  the  programmer  to  be  more  productive  and  able  to 
conceptually  manage  larger  and  more  unusual  applications. 

An  important  point  made  by  MacLennan  is  the  need  to 
separate  intensional  and  extensional  operators.  Relations, 
functions  and  sets  can  have  both  a  finite  (ex tensi onal )  or 
an  infinite  (intensional)  representation.  Many  operators  or 
combinations  of  operators  ars  i mpl ementabl e  in  either 
representation.  This  complicates  the  programmer's  life 
because  he  must  remember  the  underlying  restrictions 
involved  when  he  wishes  to  use  an  operator  which  falls  into 
one  or  the  other  category. 
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In  order  to  prevent  con-Fusion  caused  by  double  duty 
operators,  -  MacLennan  made  a  decision  to  separate  the 
operators  into  disjoint  classes,  those  which  a.r&  used  on 
■finite  sets  and  relations,  and  those  which  operate  on  the 
computable  -functions  which  represent  in-finite  sets  and 
relations.  For  example  the  application  operator  can  both  be 
used  -for  applying  a  function  to  its  argument  and  -for  looking 
up  an  item  in  a  table  (a  -finite  relation).  The  -first  case 
is  represented  -f <Sx  ,  which  applies  the  computable  -function  -f 
to  the  argument  >;.  The  more  common  mathematical  notation  is 
-f(x).  The  second  case,  which  is  denoted  by  t  i  k,  and  read 
as  't  select  x',  applies  the  -finite  table  t  to  x.  This 
simply  means  lookup  x  in  table  t  and  return  the  -first  item 
related  to  x.  Thus,  if  t  =  (1:2,  2:3,  3:4,  4:5)  and  x  =  2, 
t  i  X  would  return  '3'.  The  ': '  operator  used  above  is  just 
a  pair  making  operation  which  says  the  x:y  is  a  pair  '''<,y) 
that  is  a  member  of  the  relation  R,  hence  xRy. 

The  operators  were  further  subdivided  by  MacLennan  into 
a  primitive  class  and  non-primitive  class.  Operations  vsere 
considered  to  be  primitive  if  they  could  not  simply  be 
defined  in  terms  of  other  operations.  13  primitive 
extensional  operators  and  15  primitive  intensional  operators 
were  proposed  by  MacLennan.  These  primitive  operations  were 
supplemented  by  55  non-primitive  extensional  operators,  10 
non-primitive  intensional  operators  and  13  miscellaneous 
operations   which   were   defined  in  terms  of   the   orimitive 
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operators.  MacLennan  felt  that  these  non— pri mi ti ve 
operations  should  be  built— in  to  any  relational  programming 
language  implementation.  Because  the  work  done  in  this 
study  resulted  in  modifications  to  some  o-f  the  operators 
proposed  by  MacLennan,  a  discussion  o-f  the  operators  will  be 
presented  in  later  chapters  and  in  detail  in  Appendix  C. 

Since  a  computer's  memory  is  -finite,  representation  o-f 
large  extensional  sets  and  relations  i s  of  major  concern. 
To  this  end,  Suha  Futaci  CRef.  411  extended  MacLennan 's 
research  by  analyzing  the  complexity  of  the  algorithms 
associated  with  several  different  extensional 
representati  ons. 

Finally,  the  purpose  of  the  prototype  interpreter 
developed  in  this  research  is  to  further  advance  the  study 
of  a  relational  calculus  as  a  programming  methodology-  The 
interpreter  will  provide  a  tool  to  evaluate  the  relational 
operations  and  provide  tangible  input  for  the  selection  of 
optimal  set  of  combinators  and  relational  operators.  To 
achieve  this  several  unique  linguistic  issues  made  the 
implementation  of  this  prototype  particularly  interesting: 

1.  RPL  supported  a  syntax  which  allowed  infix  operators 
to  be  used  in  prefix  format  if  desired.  The 
expressions  (x  +  y)  and  C-f-D<x,y>  have  the  same 
semantics,  therefore  the  parser  had  to  be  designed  so 
that  both  expressions  were  ultimately  evaluated  by  the 
same  function.  The  utility  one  can  gain  by  this 
convention  is  illustrated  in  Example  1  of  Appendix  G. 

2.  Many  operators  can  be  defined  in  RPL  which  require  the 
creation  of  huge  sets  or  relations  to  be  generated  as 
an   intermediate   form.   This  is   generally   what   may 


happen  before  the  application  o-f  a  filtering  operator, 
in  which  the  final  result  requires  a  fraction  of  the 
storage  needed  by  the  intermediate  form.  This  is 
illustrated  by  the  development  of  the  'xi'  operator, 
see  Example  2  Appendix  G.  A  mechanism  to  allocate 
storage  and  perform  garbage  collection  is  imperative 
for  RPL.  Such  a  mechanism  was  provided  by  LISP's 
built-in  storage  management  system.  Having  this 
feature  available  in  LISP  was  a  major  consideration 
for  its  use  as  an  implementation  language. 

3.  The  original  grammar  shown  in  Appendix  A  was  not 
deterministic  and  had  several  productions  defined  with 
left  recursion.  It  also  contained  several  meta  symbols 
that  had  special  meaning  to  LISP  (these  included  '(', 
')',  'C',  '3',  and  ' .  ' ) .  These  i  ssues  r esul ted  i  n  the 
transformation  of  the  grammar  to  the  one  shown  in 
Appendix  B. 

4.  Twelve  of  the  fourteen  alternatives  to  the  production 
'primary'  shown  in  Appendix  B  ArB  tagged  LISP  lists. 
This  syntax  provides  a  deterministic  way  of  parsing 
these  entities  and  alleviates  the  problem  presented 
with  the  LISP  metasymbols  contained  in  the  original 
grammar.  Having  tagged  lists  for  these  structures  in 
RPL  led  to  a  type  checking  mechanism  where  most  of  the 
RPL  primitives  are  implemented  with  a  unique 
identification  tag. 

Chapters  III  through  V  will  further  examine  these  issues  and 

outine   the   overall  design  of  this   prototype.   Chapter   VI 

explains   how   to  use  the  interpreter  and   provides   several 

sample   terminal   sessions   for   illustration.   Chapter   VII 

demonstrates   the  use  of  LISP  performance  analysis   features 

and  suggests  a  direction  for  follow  on  research  in  RPL. 
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III.   WHY  LISP2 

There  were  -four  primary  considerations  for  using  LISP 
as  an  implementation  language  -for  the  RPL  interpreter:  the 
availability  o-f  the  Interlisp— 10  programming  environment, 
the  ability  to  simpli-fy  scanning  and  parsing  by  adopting  a 
LISP-like  syntax,  the  ability  to  use  LISP's  built  in  memory 
management  and  garbage  collection  system,  and  -finally,  the 
ability  to  simpli-fy  several  complex  data  structures  by 
using  built  in  LISP  structures. 

These  advantages  far  outweigh  the  sometimes  awkward 
LISP— like  syntax,  and  some  of  the  LISP  specific  input/output 
problems  that  surfaced  as  the  prototype  was  developed.  A 
discussion  of  the  all  RPL  i nput /output ,  including  the 
problems  encountered,  is  found  in  Chapter  V. 

A.   THE  INTERLISP- 10  PROGRAMMING  ENVIRONMENT 

The  Interlisp-10  system  provides  a  rich  programming 
environment.  The  tools  it  provides  to  enhance  code 
development  include  an  integrated  structure  editor,  a 
compiler  and  an  excellent  set  of  debugging  facilities. 
These  tools  operate  within  a  framework  which  does  more  than 
just  process  one  command  and  wait  for  the  next.  Three 
additional   resident   features  of  Interlisp  that  are   always 
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present  to  enhance  program  development  also  influenced  the 
choice  of  LISP  as  an  implementation  language. 

The  'Do  What  I  Mean'  (DWIM)  feature  of  Interlisp,  is 
invoked  any  time  the  system  detects  an  error.  DWIM  attempts 
to  correct  common  programming  errors  by  trying  to  logically 
predict  what  the  programmer  had  intended.  The  ability  of  the 
DWIM  feature  to  correct  spelling  and  typographical  errors  is 
a  definite  time  saver. 

Another  resident  feature  of  the  Interlisp  environment  is 
the  Programmer's  Assistant  (PA).  This  feature  basically 
maintains  a  history  list  of  all  commands  entered  by  the 
programmer.  Using  various  PA  commands  the  programmer  can 
REDO  a  sequence  of  operations,  or  use  UNDO  to  cancel 
previous  operations,  or  replace  one  variable  name  with 
another  with  the  USE  command. 

Two  particular  features  available  in  the  Interlisp 
environment.  Master scope  and  Breakdown,  ars  especially 
useful  to  future  reasearch.  Breakdown  is  an  excellent  tool 
for  conducting  performance  analysis,  allowing  the  programmer 
to  probe  the  system  to  collect  information  such  as,  the 
number  of  calls  and  amount  of  cpu  time  required  by  a 
particular  function.  The  programmer  can  even  find  out  how 
many  times  a  function  executes  another  function  (sometimes 
the  number  of  calls  on  the  LISP  CONS  function  is  a  good 
performance  indicator  in  LISP  systems). 


18 


Masterscope  is  a  remarkable  -Feature  o-F  the  Interlisp 
environment  which  creates  a  database  from  analyzing  a 
program.  Using  this  database,  the  programmer  can  interrogate 
the  system  to  -find  out  in-f  ormati  on ,  such  as  where  each 
•function  is  called  and  where  variables  are  bound  or 
re-ferenced,  or  edit  a  function  any  where  a  particular 
variable  is  used.  This  feature  is  particularly  desirable  in 
a  prototype  such  as  this  since  follow  on  research  will  have 
a  facility  to  predict  the  effect  of  changes  as  program 
revisions  3.rB    proposed  and  implemented. 

B.   SCANNER  AND  PARSER  IMPLEMENTATION  SIMPLIFIED 

Since  LISP  views  everything  in  terms  of  its  primitives, 
atoms  and  lists,  the  tokenization  function  normally  provided 
by  a  character— at— a— time  scanner  was  significantly 
simplified,  although  the  grammar  had  to  be  modified  slightlv' 
to  adopt  a  more  LISP— like  synta;; .  By  requiring  all 
expressions  to  be  enclosed  within  a  set  of  parentheses, 
parsing  an  expression  becomes  a  simple  matter  of  determining 
the  length  of  an  expression.  The  LENGTH  function  is  built 
into  LISP.  For  example  an  infix  expression  written  as 
(x  +  y)  is  recognized  by  the  length  3,  while  the  prefix 
expression  (not  p)  is  distinguished  by  its  length  of  2. 
Notice  the  requirement  for  spaces  between  the  operand  and 
operator.  Spaces  and  parentheses  are  the  only  delimiters 
used  in  RPL ' s  LISP— like  syntax.   Although  this  syntax  became 
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necessary  as  a  result  of  implementation  issues,  it  served 
the  main  objective  o-f  this  prototype,  to  develope  a  tool  to 
-Further  advance  the  study  o-f  the  use  o-F  a  relational 
calculus  as  a  programming  language. 

The  ability  to  readily  identify  infix  and  prefix 
expressions  provided  a  logical  basis  for  the  overall  design 
of  the  parsing  function. 

By   representing   all   RPL  expressions   as   LISP   lists, 
extracting   the  operands  and  operator  of  a  given   expression 
can   be   accomplished  easily  by  using  the  LISP  CAR   and   CDR 
functions.   These  functions  each  take  a  non-empty  (non-null) 
list   as   its  argument.   The  CAR  function  returns  the   first 
element   of  a  list,  whereas  the  CDR  function  returns  a   list 
containing  all  elements  of  a  list  except  the  first   element. 
Therefore,   the  CAR  function  is  used  to  extract  the  operator 
of  a  prefix  expression,  and  the  operand  is  obtained  by  first 
using   the  CDR  function  on  the  expression,   followed  by   the 
CAR   function.   For  example,   the  expression  (not  p)  can   be 
parsed  into  its  operator  and  operand  as  follows: 
operator  <=  (CAR  '(not  p) )  =  not 
operand   <=   (CAR  (CDR  ' (not  p)  =  p 
Note   that  LISP  evaluates  nested  functions  from  inside   out. 
This   means  that  to  obtain  the  operand,   the   function   (CDR 
'(not   p))  is  evaluated  first,   which  returns  the  list   (p). 
This  result  is  then  the  argument  to  the  CAR  function,   which 
extracts   the   p  from  (p>.   Since  LISP  programming   requires 
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many  instances  where  successive  CAR  and  CDR  combinations  a.rs 
required,  a  shorthand  notation  simplifies  the  operand 
extracting  code  to  the  -following: 

operand  <=  (CADR  '(not  p))  =  p 
where   the   'A'   o-f  the  CADR  -function   comes   -from   the   CAR 
■function,  and  the  'D'  -from  the  CDR  -function. 

Therefore,  simple  length  checks  on  expressions  direct 
the  parse  into  two  logical  subsets.  Once  this  is 
accomplished  the  operator  and  operands  a.re  readily 
accessible  through  a  sequence  of  CAR  and  CDR  function  calls. 
This  simplicity  made  LISP  particularly  attractive  as  an 
implementation  language. 

C.   LISP  PROVIDES  A  BUILT-IN  MEMORY  MANAGEMENT  SYSTEM 

Using  LISP  as  an  implementation  language  also  eliminated 
the  need  for  coding  a  memory  management  and  garbage 
collection  system,  since  these  features  ar&  already 
available  in  LISP.  Issues  such  as  variable  storage 
requirements  simply  went  away.  The  ability  to  let  a  proven 
system  like  Interlisp  perform  all  the  memory  management 
provided  a  sound  foundation  on  which  the  RPL  system  could 
implemented.  This  also  eliminated  a  very  error— prone  a.rBB.  of 
coding  that  might  have  created  significant  delays  in  the 
development  of  this  prototype. 
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D.   RPL  DATA  STRUCTURES  SIMPLIFIED 

Many  o-f  the  data  structures  needed  by  the  RPL 
interpreter  were  readily  available  in  LISP.  Using  built  in 
LISP  -functions  simpli-fied  and/or  eliminated  a  considerable 
amount  o-f  code  in  the  sets  and  symbol  table  data  structures. 

ALL  o-f  RPL' 5  extensional  operators  operate  on  -finite 
sets.  LISP'S  implementation  o-f  sets  is  simple,  the  LISP 
list.  Additionally,  Interlisp— 10  provides  a  complete 
assortment  o-f  set  operations  including  union,  intersection, 
set  di -f -f  erence,  cartesian  product  and  both  membership  and 
subset  boolean  functions.  Using  these  built  in  LISP 
-functions  as  a  foundation,  all  that  was  needed  to  implement 
many  of  the  set  operators  in  RPL  was  the  addition  of  type 
checking  to  ensure  the  compatibility  of  the  operands  used 
with  the  built— in  functions. 

One  of  the  main  design  decisions  in  the  development  of 
the  RPL  interpreter  was  the  choice  of  the  data  structure  to 
represent  the  symbol  table.  Several  related  design  decisions 
had  already  decreased  the  compleKity  of  the  symbol  table 
requirement.  Variable  storage  requirements  were  no  longer  an 
issue,  and  a  type  checking  tag  was  to  be  embedded  within  the 
variable's  definition.  All  that  was  needed  was  a  mechanism 
that  could  provide  a  binding  between  a  variable  name  and  its 
definition,  along  with  a  fast  and  efficient  accesssing 
function  to  retrieve  the  definition  of  a  variable  given,  its 
name  and  scope.   This  requirement  translated  directly  to  the 


LISP  association  list,  or  a— list.  The  RPL  symbol  table  is 
referred  to  as  the  RPL  environment  (denoted  globally  as  'E') 
since  it  is  the  same  structure  used  in  MacLennan's 
development  o-f  a  LISP  interpreter  written  in  LISP,  CRef.  5]- 

The  a— list  is  nothing  more  than  a  list  where  each 
element  is  a  list.  The  -following  i  s  an  example  o-f  an  a— list: 

E  =  (  (>:  1)  (y  2)  (z  3)  (t  set  1  2)  ) 
Each  element  o-f  the  a— list  represents  a  name/definition 
pair.  The  name  is  the  CAR  o-f  the  a— list  element,  its 
de-finition  is  the  CDR-  In  the  example  above  the  x,  y  and  z 
Eire  bound  to  1,  2  and  3  respectively,  while  t  is  bound  to 
(set  12). 

The  a— list  structure  in  LISP  can  be  e-f -f  i  ci  entl  y  scanned 
by  the  LISP  SASSOC  function.  This  -function,  given  an  a-list 
and  a  target,  will  return  the  a— list  element  (both  target 
and  its  de-finition)  ,  i -f  the  target  name  is  found,  otherwise 
it  returns  NIL,  indicating  the  target  was  not  in  the  found. 

The   use  of  the  a-list  data  structure  to  represent   the 
RPL  environment  provided  still  another  means  to  simplify  the 
the  overall  coding  requirements  of  the  interpreter. 


IV.   RPL  GRAMMAR  AND  SYNTAX 

A.   INTRODUCTION 

One  o-f  the  goals  of  relational  programming  is  to  develop 
a  natation  which  is  both  readable  and  has  the  manipulative 
advantages  of  a  two— dimensional  algebraic  notation.  Such  a 
notation  would  enhance  the  ability  o-F  relational  programs  to 
be  more  easily  proved  correct.  Unfortunately,  most  printers 
do  not  incorporate  the  unique  mathematical  symbols  that  sirs 
necessary  to  support  a  notation  of  this  type.  However, 
there  are  software  methods  which  enable  some  specialty 
printers  to  produce  such  symbols. 

With  such  a  notation  in  mind,  MacLennan  proposed  the 
original  grammar  shown  in  Appendix  A.  This  grammar  was 
printed  using  the  'eqn'  package  of  the  Unix  Operating 
System.  This  package  is  a  text  formatting  tool  which  takes 
an  English-like  description  of  an  equation  and  generates  the 
mathematical  symbols  for  that  equation  when  it  is  printed. 
Thus  the  notation  and  operator  names  utilized  by  MacLennan 
have  the  eqn  input  format  as  a  base.  The  utility  of  the  eqrs 
package  is  introduced  in  this  version  of  the  grammar,  but 
its  real  value  will  be  demonstrated  later  when  the  symbols 
selected  for  the  operators  are    discussed. 

MacLennan  s  grammar  accurately  presents  the  production 
rules   necessary   to   produce  legal   relational   programming 
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statements  independent  o-f  implementation  considerations. 
However,  it  is  loaded  with  le-Ft  recursion,  which  means  a 
great  deal  of  e-f-fort  would  have  been  required  to  transform 
it  into  a  -Form  -From  which  a  conventional  parser  'Tould  be 
generated.  Fortunately,  the  decision  to  use  LISP  as  an 
implementation  language  eliminated  this  concern,  but  did 
present  other  problems  which  required  modifications  to  this 
generic  grammar.  In  addition  to  basic  changes  required  by 
tht:  use  of  LISP  itself,  other  modifications  were  found  to  be 
necessary  as  the  RPL  interpreter  was  designed,  tested  and 
exercised.  The  remainder  of  this  chapter  will  discuss  the 
evolution  of  the  original  grammar  into  its  implemented  form 
presented  in  Appendix  B. 

B.   DISCUSSION  ABOUT  THE  ORIGINAL  GRAMMAR 

At  the  highest  level,  the  original  grammar  called  for  an 
interactive  session  which  consisted  of  zero  or  more  commands 
and  the  word  'done'.  Commands  could  consist  of  a  data 
definition,  a  prefix  function  definition,  input  from  a  file 
and  output  to  the  screen.  In  addition  to  the  many  built-in 
infix  and  prefix  operators,  several  special  constructs  were 
available  including  iteration,  superscription  and 
conditionals.  Finally,  a  variety  of  symbols  represented 
different  objects  within  the  language. 

The  bracket  symbols,  'C'  and  'D',  had  two  meanings  as 
printed   in  Appendix  A.    In  one  sense  their  use  meant   that 


the  object (5)  enclosed  were  optionally  required.  This 
meaning  is  still  retained  in  the  revised  grammar.  On  the 
other  hand  the  brackets  also  were  terminals  in  the  language 
which  produced  di-f-ferent  relational  structures  depending 
upon  what  objects  were  enclosed  by  them.  First,  an  in-fix 
operator  enclosed  in  brackets,  e.g.  C  +  D,  trans-Formed  the  '  +  ' 
operator  which  took  two  numeric  arguments,  into  a  pre-fix 
operator  which  took  one  argument,  a  pair  o-f  numbers.  Thus 
(x  +  y)  became  equivalent  to  C+D(x,y)  where  x  and  y  could 
be  any  number.  Second,  the  brackets  could  be  used  to  -fix 
either  the  le-ft  or  right  arguments  o-f  an  infix  operator. 
There-fore,  it  was  permissible  to  write  C3+Ilx  where  C3-!-I!  is  a 
specialized  operator  which  adds  '3'  to  any  other  single 
numeric  argument  such  as  x.  Likewise,  L+41  -fixed  the  right 
argument  to  '4'  and  would  add  any  numeric  argument  provided 
to  '4'.  Use  o-f  the  brackets  in  any  o-f  the  above  manners- 
created  a  -functional  which  could  be  combined  with  other 
-functional  s  to  create  whatever  mechanisms  were  required  to 
accomplish  a  particular  task. 

Parentheses  were  included  to  allow  natural  mathematical 
groupings  o-f  both  expressions  and  their  arguments.  Thus 
expressions  could  be  both  RPL  -functionals  or  data.  The  angle 
brackets,  '<'  and  '>',  when  used  to  enclose  data  represented 
a  special  sort  of  sequence  which  had  a  termination  symbol, 
much  like  a  LISP  list  structure  which  ends  in  'nil '. 
Finally,   braces  were  used  to  enclose  the  elements  of  a  set. 
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The  use  of  these  symbols  presented  a  convenient  method  for 
manipulating  -Functional  s,  but  con-flicted  with  the  LISP 
syntax.  The  changes  to  the  grammar  that  resulted  because  o-f 
this  are    discussed  next. 

C.   GRAMMAR  MODIFICATIONS  DUE  TO  LISP 

Unf orturnately ,  parentheses  and  brackets  have  a 
di-fferent  meaning  in  LISP.  .  In  LISP  parentheses  a.rs  used  to 
delimit  a  list  structure.  Brackets  serve  basically  the  same 
purpose,  but  the  right  bracket,  known  to  some  as  the  super 
bracket,  closes  o-f-f  all  le-ft  parentheses  which  do  not  have  a 
matching  right  parenthesis.  For  those  who  Are  familiar  with 
LISP,  this  feature  is  both  good  and  bad!  Some  say  LISP 
stands  for  'Lots  of  Idiotic  Stupid  Parentheses'  which 
summarizes  the  frustrations  encountered  with  parenthesis 
book keep i  ng . 

This  conflict  of  symbols  required  that  an  alternative 
syntax  be  developed  to  conform  with  the  LISP  list  structure 
and  still  maintain  the  semantics  of  the  RPL  language. 
To  distinguish  between  structures,  it  was  decided  to  use 
keywords  as  the  first  element  of  the  list  which  represented 
them.  These  input  formats  a.re  then  transformed  into  the 
internal  structures  required  by  the  interpreter.  Another 
problem  was  the  use  of  a  pair  of  dots  or  periods  to  indicate 
a  range  of  values.  For  example,  in  the  original  grammar  the 
range  (6.. 8)  was  equivalent  to  sequence  (6,7,8).   Use  of  the 
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character  '.'  in  RPL  created  a  symbolic  con-flict  in  LISP. 
Dots  in  LISP  Are  treated  as  special  connectors  which  -Form  a 
structure  called  a  dotted  pair.  Since  LISP  does  not 
normally  treat  dots  as  regular  characters,  anywhere  a  pair 
o-f  dots  was  required  in  the  original  grammar,  the  word  'to' 
was  substituted  in  the  new  grammar. 

Although  some  o-f  the  symbols  used  in  the  original 
grammar  did  not  pose  a  problem  in  LISP,  they  were  abandoned 
-for  consistency.  The  resulting  constructs  are  summarized  by 
example  in  Table  IV— 1.  Note  that  these  -formats  are  just 
LISP  lists  with  their  -formal  requirements  -for  spaces  between 
the  objects  in  the  list,  be  they  numbers,  words  or  any 
grouping  o-f  characters.  Thus,  a  disadvantage  o-f  LISP  is 
inherited  by  RPL,  the  importance  o-f  spaces  and  the  correct 
placement  o-f  parentheses. 

D.   GRAMMAR  MODIFICATIONS  DUE  TO  DESIGN  AND  IMPLEMENTATION 

Several  productions  were  added  to  the  grammar  due  to 
considerations  and  -factors  which  sur-faced  during  the 
implementation  process.  At  the  command  level  a  decision  was 
made  early  on  to  increase  the  flexibility  for  the  RPL 
programmer  by  allowing  him  to  define  infix  operators  as  well 
as  prefix  operators.  The  original  grammar  forced  the 
programmer  to  define  infix  operators  in  a  prefix  format. 
That  meant  that  his  normal  thinking  about  an  infix  operator 
had  to  be  altered  to  fit  the  prefix  form  of  a  function  which 
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Table  IV-1 


—  RPL  Grammar  Modi -f  i  cat  i  oni 
Required  By  Use  Of  LISP 


RPL  SYNTAX 

Original        !         Final 

c  +  : 

(op  +) 

C3+D 

(Isec  3  +) 

c+4: 

(rsec  +  4) 

(1,2,3,4,5) 

(seq  12  3  4  5) 

(1. .5) 

(seqrange  1  to  5) 

Cl,2,3,4,5> 

(set  12  3  4  5) 

CI.. 5D 

(setrange  1  to  5) 

■-.1  ,  ^  ,  ^-  '■ 

(list  1  2  3) 

<  1 .  .  5  > 

(listrange  1  to  5) 

iterCp->f D 

(iter  p  ->  f) 

Cif  p  ->  f;gl 

(if  p  ->    f  ;  g ) 
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takes  a  single  argument  -  in  this  case  a  list  containing  two 
arguments.  Internally,  all  operators  can  be  considered  as  a 
prefix,  but  most  people  have  become  accustomed  to  thinking 
about  binary  operators  in  the  in-fix  sense.  For  example,  to 
add  2  and  3  in  RPL  it  is  natural  to  write 
'(display  (2  +  3))'.  But  to  de-fine  the  in-fix  operator 
'plus'  which  would  do  the  same  thing,  a  user  would  have  to 
enter  ' (plus  (x  y)  ==  (x  +  y)) '. 

To  alleviate  this  inconsistency,  a  production  rule  was 
added  to  allow  the  programmer  to  de-fine  the  operator  'plus' 
in  the  more  natural  way  and  to  use  it  the  same  as  any  other 
in-fix  operator: 

De-f  i  n i  t  i  on  =  >      ( x  pi  us  y  ==  ( x  +    y )  ) 
Example     =>      (display  (2  plus  3)) 

The  second  major  addition  to  the  grammar  was  a  similar 
construct  to  the  LAMBDA  expression  in  LISP.  This  construct 
provides  the  programmer  with  a  great  deal  o-f  -flexibility  and 
was  incorporated  into  RPL  as  a  '-func'  expression  to  insure 
no  confusion  with  the  LISP  equivalent.  Like  the  LAMBDA 
expression  in  LISP,  the  func  expression  consists  of  the  name 
of  the  function,  a  list  of  formal  parameters,  and  the  body 
o-f  the  function  in  terms  of  the  formal  s.  Thus,  the  RPL 
programmer  can  now  define  functions/relational  operators  in 
three  ways,  directly  using  the  'func'  expression,  as  a 
prefix  operator,  or  as  an  infix  operator.  For  comparison, 
the   three   types  of  definitions  for  the  'plus'  operator   as 
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described  on  the  previous  page  aire    shown  below: 

Direct:    (plus  ==  (func  (x  y>  (x  +  y) > ) 
Pre-fix:   (plus  (x  y)  ==  (x  +  y)  ) 
Infix:     (x  plus  y  ==  (x  +  y) ) 

From  the  examples  above,  it  appears  that  parentheses  are 
going  to  plague  RPL  just  as  they  do  LISP,  but,  as  will  be 
discussed  in  a  later  chapter,  the  Interlisp  environment 
provides  a  mechanism  which  allows  the  outside  parentheses  to 
be  dropped  when  inputting  commands,  and  actually  assists  in 
keeping  tract  o-f  correct  placement  o-f  parentheses. 

The  next  modification,  which  was  deemed  appropriate  to 
make  the  programmer's  life  a  little  easier,  dealt  with  the 
RPL  command  'display'.  At  the  command  level  this  word  had 
to  be  written  to  obtain  output  to  the  screen.  It  quickly 
became  apparent  that  it  was  cumbersome  to  type  'display'  in 
order  to  see  every  result  of  a  computation.  So,  the 
alternative  input  forms  of  'dis'  and  'd'  were  added. 
Finally,  even  these  forms  were  made  optional,  requiring  the 
interpreter  to  detect  automatically  the  programmer's  intent. 

As  mentioned  earlier  in  this  chapter,  the  original 
grammar  only  permitted  input  from  a  file.  The  intent  was  to 
allow  the  user  to  create  a  series  of  RPL  data  structures 
outside  of  the  RPL  environment  and  to  read  them  m  as 
necessary  during  a  session.  It  became  apparent  that  there 
also  was  a  need  to  save  data  created  during  a  session.  For 
example,   a  database  in  RPL  is  just  a  large  set  of   records. 
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where  each  record  is  a  relation  between  the  -field  names  and 
their  associated  values.  It  is  desirable  to  be  able  to  read 
the  entire  database  structure  from  a  -file,  update  it  in  some 
fashion  during  a  session,  and  rewrite  it  back  to  a  -file.  To 
allow  this,  another  production  was  added  at  the  command 
level  which  permitted  commands  o-f  the  -form: 

■file  string  ==  expression 

Execution  o-f  a  command  of  this  type  would  place  the 
value  of  the  evaluated  expression  into  a  file  with  a 
filename  given  by  the  'string'  argument  of  the  operator 
'file'.  For  example,  consider  an  existing  database  stored 
in  a  file  called  'OldMaster'  and  an  updating  function, 
called  'Update',  which  when  given  a  database  as  an  argument 
would  modify  the  value  of  a  selected  field  in  all  records 
and  return  the  updated  database.  With  this  new  production 
it  is  then  possible  to  execute  the  following  command: 

(file  "NewMaster"  ==  (Update  (file  "OldMaster"))) 
This  command  would  read  the  'OldMaster'  file  in,  execute  the 
'Update'   function  with  'OldMaster'  as  its  argument  and  then 
rewrite  the  updated  database  to  the  file  'NewMaster'. 

The  one  problem  with  this  construct  is  that  it  should 
not  be  used  to  store  function  definitions  to  a  file.  A 
function  definition  has  associated  with  it  an  environment  of 
definition.  This  environment  consists  of  all  previously 
defined  functions,  their  environments,  and  any  data 
definitions   made   up   to   the  point  of   definition   in   the 


session.  Since  the  environment  is  nothing  more  than  an 
association  list  which  contains  the  bindings  o-f  all  names  to 
their  values,  this  list  can  become  extremely  long  in  a  short 
period  o-f  time.  Internally,  pointers  ars  used  to  conserve 
space,  but  when  printed,  the  entire  environment  chain  is 
produced,  which  could  result  in  many  pages  o-f  in-f ormation. 
As  discussed  in  Chapter  V  this  could  cause  a  -fatal  problem 
or  be  a  terrible  inconvenience  at  the  least.  Another 
■feature  o-f  the  RPL  system,  which  is  discussed  in  more  detail 
in  Chapter  V,  allows  function  de-finitions  created  during  a 
session  to  be  saved  for  future  use  and  thus  avoids  the 
problems  which  could  be  created  with  the  file  command  in  the 
output  mode. 

The  function  definition  and  its  associated  environment 
did  lead  to  two  other  grammar  modifications.  First,  the 
initial  implementation  of  the  'displa-y'  command  returned  the 
evaluated  form  of  the  argument.  Therefore,  the  result  of 
executing  such  a  command  returned  something  totally 
different  from  what  the  user  typed  in  and  compounded  the 
problem  with  environment  length. 

For  example,  say  the  user  typed  in  the  following  data 
def  i  ni  tion : 

(x  ==  (seq  12  3)) 
Later   in  the  session  he  decides  to  remind  himself  of  how   x 
was  defined.    He  types  in  the  command  (display  x) ,  but  what 
is   returned   is   not   his   definition,    but   the   internal 


representation  o-f  the  sequence  he  de-Fined: 

(Erel  (12)  (2  3)) 
Likewise,  if  he  had  de-fined  the  -function  -F  as: 

( -f  >',    ==  ( X  t  i  mes  x  )  ) 
and  then  entered  (display  -F )  ,  he  would  see: 

closure  x  (k  times  x)  ... 
Internal   representations   will  be  discussed   in   detail   in 
Chapter  V.    To   an   un-f  ami  liar  user,   this  would   be   quite 
con-Fusing  and  so  the  DISPLAY  -Function  was  modi-Fied  to  return 
the  user  de-Finition  as  it  was  typed  in. 

A-fter  one  becomes  -Familiar  with  the  RPL  language  it 
becomes  desirable  to  sometimes  see  the  evaluated  internal 
representation  o-F  any  particular  name.  This  -Feature  is 
especially  helpful  when  trying  to  debug  a  command  that 
didn't  work.  The  'val  identifier'  command  was  developed  to 
handle  this  need  and  was  extended  to  meet  the  need  to  see 
the  overall  session  environment  or  the  environment  of  any 
particular  function. 

Every  function  definition  has  its  environment  of 
definition  attached  when  it  is  converted  into  its  internal 
representation.  In  LISP,  that  means  a  simple  pointer  is 
added  to  the  list  which  describes  the  function.  When  this 
definition  is  printed,  however,.  that  simple  pointer  is  the 
beginning  of  a  very  long  list  of  pointers  which  may 
represent  atoms  or  other  lists  of  atoms  to  be  printed. 
Consequently,   pages   of   information  Are       printed   to   the 
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screen.  When  this  same  information  was  in  evaluated  -form, 
the  result  was  excessive  and  usually  resulted  in  aborting 
the  session.  To  prevent  this  surge  o-f  unwanted  i  n-f  ormati  on  , 
the  DISPLAY  -function  was  modified  to  print  only  the  first 
three  elements  of  a  function  definition,  its  name,  its 
formal  paramenters,  and  its  body.  Unfortunately,  this 
modification  also  eliminated  the  ability  to  ever  look  at  any 
environment.  So,  the  'env'  command  level  productions  were 
created.  They  allow  the  user  to  look  at  the  overall  session 
environment  or  the  environment  of  any  designated  function. 
These  features  will  be  discussed  further  in  the  input /output 
section  of  Chapter  V- 

E.    INFIX  VS  PREFIX  OPERATORS 

At  first  view  the  myriad  of  operators  shown  in 
MacLennan's  grammar  seem  overwhelming  and  confusing,  but  one 
must  remember  that  many  of  the  words  and  symbols  chosen  were 
based  upon  the  Unix  eqn  input  format.  Due  significantly  to 
the  way  the  RPL  interpreter  was  developed,  many  of  the 
prefix  operators  became  more  naturally  suited  to  an  infix 
format.  Some  operators  were  discarded  as  no  longer  relevant 
because  of  changes  in  the  way  argument  lists  were 
represented.  Others  were  added  because  of  a  new  found 
utility  based  upon  the  same  change  just  mentioned.  It  is 
also  here  where  the  true  utility  of  the  eqn  text  formatting 
tool   becomes  apparent.    The  sheer  quantity  of   operations. 


due   mostly  to  the  goal  o-f  preventing  overloaded   operators, 
required  a  great  deal  o-f  distinct  symbols.    The  purpose  and 
use   o-f  these  operators  ars    discussed  in   Appendix  C,   but 
their  names,  original  input  -forms,  -final  input  forms  and  the 
eqn   publication   -forms  are    shown   in   Appendix  E.    This 
appendix   summarizes   the   -final   changes   to   the   grammar, 
highlights  the  conversion  o-f  some  pre-fix  operators  to  in-fix, 
and   also   serves   as   a  concise   guide   to   the   relational 
operators  and  their  syntax.   Finally,  the  current  grammar  as 
implemented   by  the  RPL  interpreter  is  shown  at  Appendix  B 
and    includes   all   the   modi -fi  cat  i  ons   discussed   in   this 
chapter. 


V.  INIiRPRiliB  DESIGN  and  development 

Previous  chapters  have  illustrated  the  rationale  behind 
the  choice  o-f  LISP  as  an  implementation  language  and  the 
resulting  modi -fi cations  that  became  necessary  to  adapt  the 
the  original  RPL  grammar.  The  purpose  o-f  this  chapter  is  to 
-focus  on  issues  related  to  the  implementation  the  of  RPL 
primitives  and  the  overall  structure  o-f  the  interpreter.  In 
addition,  since  MacLennan's  report  CRe-f.  2]  illustrates  how 
many  RPL  operators  can  be  implemented  by  de-fining  them  in 
terms  o-f  a  set  primitive  operators,  the  mechanism  used  to 
implement  the  extensible  nature  of  RPL  is  also  an  issue  that 
will  be  discussed. 

A.   RPL  PRIMITIVES 

RPL  contains  three  fundamental  elements,  individuals, 
sets  and  relations.  The  function,  which  is  merely  a  special 
case  of  a  relation,  was  added  to  the  list  of  primitives 
because  it  required  a  unique  internal  representat i on - 

The  indivisible  data  element  found  within  RPL  is  the 
individual.  This  data  type  is  equivalent  to  LISP  atomic 
values  and  is  implemented  accordingly.  Numeric,  string  and 
boolean  scalars  common  to  all  programming  languages  are 
available   in   RPL-   Strings  must  be  enclosed   in   quotation 
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marks  to  distinguish  them  -From  LISP  literal  atoms.  Literal 
atoms  in  LISP  Ars  used  to  implement  the  boolean  values, 
'true'  and  '-false',  and  all  identifiers. 

2.  Sets 

The  set  in  RPL  is  implemented  as  a  LISP  list 
containing  the  tag  'Eset'  as  its  -First  element.  The  tag 
'Eset'  is  used  both  to  distinguish  the  internal  set 
representation  in  evaluated  -Form  from  its  input  format  and 
as  a  type  checking  device.  For  example,  the  set  having  the 
internal  representation  (Eset  12  3)  may  have  been  input  as 
(set  1  2  3)  or  (set  a  b  c)  ,  where  a.—c.  have  appropriate 
internal  bindings. 

3.  Rel_ati_ons 

The  finite  relation,  being  a  special  kind  of  set, 
has  an  internal  representation  that  closely  resembles  the 
set.  The  relation  requires  a  special  type  of  LISP  list, 
called  an  association  list  or  a— list.  This  particular  data 
structure  was  chosen  to  implement  the  relation  for  two 
reasons.  First,  the  mathematical  notation  for  a  relation 
closely  resembles  an  a-list.  For  example,  the  mathematical 
rel at  1  on 

C  (1,2)   (2,3)   (3,4)   (4,5)  > 
is  represented  in  RPL  as  the  following  tagged  a-list: 

(Eset  (1  2)   (2  3)   (3  4)   (4  5)  ). 
Second,   the  desire  to  use  relations  as  tables,  suggests  the 
choice  of  a  data  structure  that  can  be  searched  quickly   and 
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e-F-f  iciently.    The    LISP   SASSOC   -Function   provides    this 
capability  when  called  with  an  a— 1 i st  as  its  argument. 

Since  many  built— in  RPL  operators  Are  designed  to 
operate  on  relations,  to  perform  the  -Fast  recognition 
necessary  -For  type  checking,  the  'Erel  '  tag  was  used  in 
place  o-F  the  'Eset'  tag.  This  e-Fficiency  was  not  free.  The 
cost  of  distinguishing  relations  as  a  special  type  of  set 
was  paid  for  by  the  increased  complexity  in  set  operations 
and  the  coding  necessary  for  coercion  functions, 
a.   The  Evolution  of  'Erel 

During  the  earlier  stages  of  development, 
after  the  decision  to  have  the  'Erel '  tag  to  distinguish 
relations,  it  seemed  logical  to  extend  this  principle  to 
special  kinds  of  relations,  namely  sequences  and  arrays. 
There  were  many  operators  within  RPL  designed  to  operate  on 
these  kinds  of  relations,  therefore,  for  the  same  rationale 
behind  having  the  'Erel'  tag,  the  'Eseq'  and  'Elist  tags 
were  adopted. 

The  language  incorporated  two  input  formats 
as  convenient  ways  to  enter  mathematical  sequences  and 
arrays.  The  familiar  mathematical  notation  for  the  two 
entities  was  reflected  in  the  original  grammar.  The  sequence 
was  shown  in  the  original  grammar  as  (  2,  4,  6,  8  ) ,  whereas 
the  Array  (n— tuple) ,  was  represented  as  <  2,  4,  6,  8  >.  Both 
of  these  a.r&    mathematically  relations: 
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(  2,  4,  6,  8  )  <=>  i     (2,4)   (4,6)   (6,8)  > 

<  2,  4,  6,  8  >  <=>  C  (1,2)   (2,4)   (3,6)   (4,8)  >. 
This  was  modified  to  the  following  LISP-like  syntax: 

(  2,  4,  6,  8  )  =>  (seq  2  4  6  8), 

<  2,  4,  6,  8  >  =>  (list  2  4  6  8). 

For  completeness,  an  input  syntax  was 
adopted  to  permit  relations  to  be  entered  through  the  use  of 
the  tag  'rel ' ,  in  place  of  the  'set'  tag,  and  the  use  of  the 
RPL  pair  making  operator,  ': '.  The  input  format 

(rel  (1:2)   (2  :  3) ) , 
was  represented  internally  in  RPL  as  the  relation 

(Erel  (1  2)  (2  3) ) . 

Although  the  decision  to  have  different  tags 
to  distinguish  each  special  kind  of  set  made  type  checking 
very  fast  and  efficient,  having  numerous  internal  forms  that 
are  mathematically  equivalent  was  a  problem  not  easily 
solved.  Consider  the  relations  r,  s  and  1  bound  as  follows: 

r  <=  (  Erel  (12)  (2  3)  ) 

s  <=  (  Eseq  (12)   (2  3)  ) 

1  <=  (  Elist  (1  2)   (2  3)  ) . 
Any  operation  applied  to  any  of  these  relations  should  yield 
the   same  results.   Additionally,  an  equality  test  comparing 
any  two  of  them  should  return  'true  .  This  situation  becomes 
even  more  muddled  if  the  following  binding  is  made: 

s'  <=  (  Eset  (12)  (2  3)  ) . 
Now   there  Ars    four  variables,   bound   to   four   physically 
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dH^-ferent  representations,  which  must  be  evaluated  as 
equivalent  structures.  This  is  like  trying  to  do  computation 
with   numbers  given  -four  di-f Cerent  number  systems. 

The  problems  created  by  having  -four  objects 
with  the  same  meaning  was  not  solvable  without  a 
considerable  amount  o-f  coding.  A  coercion  -function  -for 
every  possible  representation  was  required.  The  global 
variable  'ESETS',  a  list  o-f  tags  considered  legal  for  set 
operations,  had  to  be  established.  Precedence  rules  had  to 
be  implemented  to  determine  what  tag  to  af-fix  to  the  result 
o-f  a  set  operation.  The  equality  check  had  to  be  designed  to 
-focus  on  tagless  lists.  All  this  additional  e-f-fort  hardly 
seemed  cost  e-f-fective  -for  a  prototype,  especially  when  the 
algorithm  for  the  coercion  function  to  create  a  sequence 
was  considered.  Coding  to  ensure  a  set  is  a  fully  connected 
ir reflexive  bijection  (definition  of  a  sequence  used  in  by 
MacLennan  CRef.  2:  p.  22  3)  is  not  trivial  task. 

It  vgas  time  to  re— examine  the  efficiency 
gained  in  the  type  checking  mechanism  by  having  tags 
distinguish  various  kinds  of  sets,  versus  the  increased 
coding  complexity  necessary  to  ensure  the  semmantics  is  not 
altered  in  this  new  syntax.  This  involved  screening 
MacLennan 's  report  CRef.  21  to  classify  operators  based  on 
their  operands  and  their  output.  It  was  observed  that  when  a 
prefix  operator  required  two  arguments,  a  two  element 
sequence  was  used.  For  example,  the  function  defined  as 
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sum  ==  (k  +  y) 
was  used  with  the  synta;: ,  sum  (2, 4).  Further  analysis  found 
cases  where  the  use  o-f  the  sequence  was  inconsistent  with 
its  -formal  de-finition.  This  discovery  led  to  the  RPL  list, 
depicted  as  <M,y>  in  the  original  grammar,  replacing  the 
seguence  as  the  -form  -For  arguments  to  functions  like  'sum'. 
This  shift  from  sequences  to  lists  will  be  discussed  in  more 
detail  in  the  following  subsection. 

The  significance  of  the  shift  from  sequences 
to  lists  as  functional  arguments  was  that  the  sequence  and 
its  operators  were  now  considerably  less  important  to  the 
RPL  programmer.  This,  along  with  the  coding  complexity 
described  earlier,  resulted  in  the  decision  to  abandon  the 
'Eseq'  tag.  Additionally,  knowing  a  set  is  a  relation  makes 
it  is  easy  to  verify  if  the  relation  is  a  RPL  list.  This 
resulted  in  the  elimination  of  'Elist'  tag  also.  By 
eliminating  these  two  tags  a  viable  compromise  had  been 
made. 

The  special  input  formats  discussed 
previously  were  kept  in  the  language  for  user  convenience, 
with  the  tag  'Erel'  being  appended  internally,  vice  'Eseq' 
or  'Elist',  to  the  a-list  that  made  up  the  relation. 
Sequence  operators  were  still  provided  but  error  checking 
was  limited  to  verifying  that  operands  are  relations.  This 
put  the  responsibility  on  the  programmer  to  ensure  proper 
arguments  were  used. 
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The  end  result  o-f  the  trade— of -F  analysis, 
weighing  the  issues  o-f  type  checking  ef^^iciency  verses  code 
complexity,  brought  to  light  the  detail  and  depth  o-f 
planning  required  to  design  an  e-f-fective  so-ftware  system. 
Language  -features  Sirs  not  free,  and  simple  solutions  to  one 
problem  may  well  create  a  snowball  e-f-fect  in  complexity  in 
other  areas.  Unfortunately,  sometimes  this  is  not  obvious 
without  modeling  the  implementation. 

b.   The  Sequence  Loses  Significance  in  RPL 

The  sequence  is  used  by  MacLennan  CRef.  2  3 
to  represent  an  argument  to  mul ti -parameter  prefix  operators 
and  functions.  Many  applications  used  the  sequence 
operators,  alpha  and  omega,  to  extract  the  individual 
operands  from  the  two  element  sequences.  In  the  sequence 
(x,y) ,  alpha  and  omega  were  used  to  extract  x  and  y 
respectively.  These  operators  can  only  be  used  on  a  pure 
sequence.  Graphically  sequences  can  be  represented  as  being 
a  fully  connected  structure,  with  no  cycles,  and  all  -^rroi^is, 
pointing  in  one  direction  (see  Chapter  VI). 

In  addition,  the  DELTA  function  was 
introduced  to  create  a  mechanism  that  could  duplicate  an 
argument  for  function  application.  For  example,  the  squaring 
function  would  be  defined  as  follows: 

sqr  ==  CtimesH  o  DELTA. 
The   DELTA   function  duplicates  any  argument   returning   the 
sequence  shown 


DELTA  n  =>  (n  ,  n) . 
There-fore  sqr  4  can  be  written 

sqr  4  =>  Ctimes:  (4  ,  4). 
This  looks  perfectly  reasonable,   except  that  (4,4)  is  not 
a  sequence.  By  de-finition  a  sequence  is  irre-Flexi ve. 

The  problems  created  by  the  irre-flexive 
property  o-f  the  sequence  are  discussed  in  MacLennan's 
research  CRe-f.  2:  p.  22]  in  considerable  detail.  He  also 
suggests  an  alternative  de-finition  to  the  sequence,  but  the 
structure  used  as  the  argument  to  -functions  remained 
sequences  throughout. 

The   -failure  o-f  the  sequence  as  an   argument 

to   -functions   became  obvious  as  many  o-f   the   ex tensional  1  y 

de-fined   operators   were   implemented.    In   many   instances 

de-finitions   used   the   alpha  and  omega  operators   on   their 

arguments.   These  functions  would  not  work  for  inputs  of  the 

form  (n,   n).  Functions  that  were  defined  in  terms  of  DELTA, 

alpha   and /or  omega  would  not  work  on  any  input,   since   the 

operati  ons 

alpha  o  DELTA 
and 

omega  o  DELTA 

ar&    undefined. 

The    RPL    list,    which    had    notational 

similarities   to  the  sequence,   <K,y>  verses   (x,y),   was   a 

logical   replacement   to   the  sequence  as   the   argument   to 

functions.   The   list   construct  <n,   n>,   which  is  just   an 

i 
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array,  was  well  de-fined,  -filling  the  void  not  covered  by  the 
sequence.  The  'sel'  operator,  when  used  with  RPL  list, 
provided  a  means  to  extract  each  operand  to  a  -function, 
similar  to  the  alpha  and  omega  used  previously  on  the 
sequence.  The  operators  Csel  11  and  Csel  23  extract  the  ;< 
and  y  components  -from  the  list  <x,y>.  DELTA  had  to  be 
rede-fined  to  return  the  list  <n,n>.  The  !  1  operator,  which 
was  de-fined  as 

■f  !  !  g  =>  (  -f  (k)  ,  g(x)  ) 
was  also  refined  to 

-f  !  :  g  =>  <  -f  (x)  ,  g  (x)  >. 
Essentially,    de-finitions    where  ix  ,y)       appeared   in   the 
original  report  were  replaced  by  <x,y>,   and  alpha  and  omega 
were  replaced  by  either  Csel  13  and  Csel  23  ,  respectively. 

The  unsui  tabi  1  i  ty  o-f  the  sequence  as  a 
argument  to  a  -function  has  in  no  way  diminished  the  power  o-f 
RPL.  The  list  structure  is  just  as  easy  to  manipulate 
algebraically,  and  is  more  versatile  in  many  respects.  For 
example  with  the  use  o-f  the  '-func'  a  programmer  can  de-fine 
functions  of  the  form 

add3  ==  (  func  (x  y  z)  (  (x  -•-  y)  +  z)  ). 
This  can  be  used  for  any  number  of  variables.  A  flexibility 
not  possible  with  sequences.  From  a  system  development 
aspect,  it  is  far  easier  to  perform  error  checking  on  lists. 
If  anything  the  shift  from  sequences  to  lists  made  RPL 
system  development  and  programming  tasks  simpler. 


^-   EyQcti_gn5 

Since  RPL  is  extensible,  both  user  de-fined  functions 
and  system  -functions  that  are  de-fined  in  terms  o-f  a  kernel 
o-f  primitive  functions  have  the  same  internal 
representation.  This  representation  consists  of  four 
elements,  the  keyword  'closure',  the  formal  parameters,  a 
function  body  and  an  environment  pointer. 

The  keyword  'closure'  is  adopted  from  its  use  by 
MacLennan  CRef.  5:  pp.  436-437D.  He  defined  a  closure  as 
having  two  elements,  which  can  be  used  to  implement  static 
scoping,  an  instruction  part  (ip)  and  an  environment  part 
(ep).  The  ip  is  a  pointer  to  the  part  of  the  code  which 
defines  the  function,  and  the  ep  is  a  pointer  to  the 
context  of  a  given  function,  which  is  all  the  names  visible 
to  that  function.  For  RPL  purposes  the  keyword  'closure'  is 
merely  a  type  checking  tag  like  ' Eset '  and  'Erel'.  However, 
the  basic  structure  used  by  MacLennan  to  implement  static 
scoping  in  his  model  LISP  interpreter  was  also  used  in  RPL. 
Figure  V-l  shows  the  parallel  between  MacLennan 's  model  and 
RPL. 

The  formal  parameters  and  the  body  of  the  function 
correspond  to  the  ip  used  by  MacLennan.  Formal  parameters 
are  represented  in  LISP  as  either  a  literal  atom  or  a  list 
of  literal  atoms.  The  body  of  the  function  is  a  LISP  list 
which   is  syntactically  a  RPL  expression.   The  expression  is 
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de-fined  in  terms  o-F.   the  -formal  parameters  along  with   names 
de-fined  in  -functi  on  '  s  "environment  of  de-finition. 

The  environment  pointer  is  a  snapshot  o-f  the  RPL 
system  environment  at  the  time  a  function  is  defined.  More 
precisely,  this  pointer  corresponds  to  the  RPL  system 
environment  pointer  when  the  function  was  defined  (this 
takes  advantage  of  the  way  LISP  implements  the  list 
internally).  In  view  of  this,  all  names  defined  by  the  RPL 
programmer  during  a  session  and  all  RPL  built— in  functions 
a.re    within  a  function's  environment  of  definition. 


MacLennan's  Model 


RPL  Model 


closure 


closure  formals  body   ep 


lambda   formals   body 

Figure  V— 1  —  Similarity  between  Models 

Section  D,  which  illustrates  the  process  of 
evaluating  funcions  will  elaborate  on  how  RPL  system  binds 
formal  parameters  to  their  actuals. 

B.   RPL  ENVIRONMENT 

As  discussed  in  Chapter  III  two  of  the  main  advantages 
for  using  LISP  as  an  implementation  language  were  the 
ability   to   use   built— in  LISP  data  structures   and   LISP's 
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memory  management  system.  By  embedding  tags  as  part  o-f  the 
internal  definition  o-f  sets,  relations  and  functions,  and 
using  the  LISP  boolean  -functions,  NUMBERP  and  STRIhJGP,  on 
individuals  (non-lists),  the  type  checking  mechanism  was 
easily  established.  There-fore,  many  o-f  the  attributes 
normally  stored  in  the  symbol  table  o-f  conventional  language 
systems  were  eliminated.  Combining  this  with  the  static 
scoping  mechanism  discussed  in  the  previous  section  reduced 
the  RPL  symbol  table  requirements  to  a  mechanism  that  would 
bind  each  name  with  a  pointer  to  its  internal  definition  and 
provide  a  fast  means  of  accessing  that  definition. 

LISP  implements  the  list  very  efficiently  by  using 
pointers  to  cells  in  memory.  Since  every  list  can  be  broken 
into  two  components,  its  CAR  and  CDR,  the  list  was  a  simple 
but  logical  choice  of  a  structure  to  be  used  to  associate  a 
name  with  its  definition.  The  name  and  its  definition  form  a 
pair  corresponding  to  the  CAR  and   CDR  of  a  list. 

A  list  construction  function,  appropriately  called 
CONS,  is  available  in  LISP.  CONS  takes  two  arguments,  the 
first  argument  is  the  CAR  of  the  list,  the  second  argument 
IS  the  CDR.  Using  this  function  a  binding  G3.n  be  made 
between  a  name  and  its  definition.  This  is  illustrated  in 
Figure  V— 2. 

The  most  primitive  of  LISP  lists  is  called  a  dotted 
pair.  Like  any  other  list,  dotted  pairs  have  a  CAR  and  a 
CDR.   Dotted   pairs  get  their  distinction  from  the  dot   that 
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sometimes  separates  the  CAR  and  CDR  when  displayed.  The  CONS 
•function  usually  adds  its  first  argument  to  the  beginning  of 
a  list,  which  is  the  second  argument.  Most  LISP  lists  end 
with  a  NIL  marker,  thus  (CONS  1  NIL)  is  the  list  (1). 
However,  list  without  a  NIL  marker  occurs  when  the  second 
argument  to  the  CONS  -function  is  an  atom  (and  not  NIL). 
Since  the  second  argument  has  no  NIL  marker,  the  list 
created  by  CONS  in  this  instance  has  no  NIL  marker  either 
and  it  looks  a  little  strange  when  printed.  LISP  prints  its 
lists  by  following  the  pointers  of  each  element-  A  dot  '. 
is  printed  preceding  the  last  element  if  there  is  no  NIL 
marker  associated  with  it.  This  is  why  a  dot  is  shown  in 
the  illustration  (f  .  def ) .  In  many  LISP  implementations  the 
dot  '. '  is  the  same  operation  as  the  CONS  function. 


def 


CONS 


(f  .  de-f) 


CAR   CDR 


Figure  V— 2  —  Typical  Binding 

Having  each  name  associated  with  its  definition  by 
using  the  CONS  function  is  not  a  novel  idea  to  a  LISP 
programmer.  A  1 i st  of  these  pairs  is  called  an  association 
list  or  a— list  in  LISP.   To  search  these  constructs   rapidly 
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LISP  provides  the  SASSOC  -function.  This  -Function,  when 
called  with  a  target  and  an  a-list,  will  compare  the  target 
to  the  CAR  (or  name  pointer)  o-f  each  element  o-f  the  a— list. 
I-F  the  target  is  -found  the  entire  element  is  returned. 
Taking  the  CDR  o-f  this  result  provides  the  de-finition.  This 
process  is  encapsulated  by  the  RPL  system  -function  LOOKUP. 
The  simplicity  and  e-f-ficiency  o-f  this  data  structure  makes 
it  an  excellent  mechanism  to  implement  the  RPL  environment, 
especially  in  a  prototype. 

Although  e-f-ficiency  issues  of  RPL  will  be  topics  for 
-future  research,  the  design  o-f  the  RPL  environment  using  the 
the  a— list  owes  its  e-f-ficiency  to  its  LISP  implementation. 
By  taking  advantage  o-f  the  characteristics  o-f  the  LISP  list 
and  its  most  basic  list  constructor  to  bind  names  and 
definitions  it  was  hoped  that  efficiency  could  be  inherited 
from  LISP.  Pointers  used  in  many  PASCAL  like  languages  e.rs 
often  hard  to  use  and  error— prone.  LISP  provides  the 
efficiency  of  using  pointers  without  the  programmer  having 
any  conscious  awareness  of  their  implementation.  This  level 
of  abstraction  simplified  the  programming  task  considerably. 

C.   PARSING  RPL 

In  most  languages  user  input  is  first  analyzed  by  a 
scanner.  However,  by  using  LISP  as  an  impl ementai on  language 
and  making  some  minor  modifications  to  the  grammar  to  adopt 
a   LISP-like  syntax,   the  functionality  of  the   scanner   was 
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eliminated.  The  RPL  command  line  is  simply  a  LISP  list. 
Using  various  LISP  -funcions  to  examine  the  syntax  o-F  this 
list,  the  semmantics  o-f  the  command  is  extracted. 

Parsing  the  grammar  shown  in  Appendix  B  can  be 
accomplished  by  dividing  the  parse  into  two  stages.  The 
basic  input  to  the  interpreter  is  the  RPL  command  line. 
Determining  which  of  the  nine  di-F-ferent  commands  is  being 
used  is  the  -first  stage  o-f  the  parsing  task.  Five  o-f  the 
commands  require  the  evaluation  o-f  a  RPL  expression.  Parsing 
the  expression  is  the  second  parsing  stage. 

The  -first  parsing  stage,  which  is  accomplished  by  the 
RPL  system  -function  EXECUTE,  classi-fies  the  RPL  command.  ALL 
RPL  commands  with  the  exception  o-f  the  command  (  done  )  can 
be  classi-fied  as  shown  in  Figure  V— 3.  The  utility  function 
POSIT  scans  the  command  line  and  returns  the  postion  of  the 
atom  '=='.  If  '=='  is  not  part  of  the  command  line  POSIT 
returns  13.  Using  this  information,  combined  with  checking 
the  length  of  the  command  line,  syntax  is  verified  and  the 
parse  is  guided  to  either  the  function  DEF_BINDINGS  or 
DISPLAY  for  every  command  except  the  'done'  and  'file' 
commands.  The  'file'  and  'done'  commands  a.r&  directed  to  the 
FILE_WRITE  and  EXIT  RPL  systems  function  respectively. 

The  function  DEF_BINDINGS ,  expecting  one  of  the  first 
three  input  forms  shown  in  Figure  V— 3 ,  completes  the  parse 
by  checking  the  length  of  the  command  line.  Knowing  the 
length   of   the   command,   the  name  and   expression   can   be 


extracted  using  the  CAR  and  CDR  -functions.  Once  the 
expression  is  isolated  it  can  be  evaluated  by  calling  the 
■function  EV. 

If  the  expression  is  evaluated  successfully  several 
events  occur.  First  the  CONS  -function  binds  the  name  to  the 
evaluated  expression,  and  this  pair  is  consed  onto  the  RPL 
environment,   E.  Second,  the  name  is  consed  onto  the  command 


(  -f  ==  exp  ) 

(  f  X  ==  exp  ) 
(  X  f  y  ==  exp  ) 


contain  the  atom  '  = 
binding  required 


(  -file  "string"  ==  exp  ) 


(  display  exp  )  — 

(  val  identi-fier) 

(  env  ) 

(  env  identi-fier) 


contain  the  atom  ' -■ 
-file  10  required 


do  not  contain  ' == 
display  required 


(  done  ) 


do  not  contain  ' == 


Figure  V-3  —  Command  line  analysis 


line  and  is  added  to  the  a-list  called  USERDEFS  (giving  the 
user  the  ability  to  save  his  commands  to  a  -file;  see 
Chapter  VI).  Finally,  i -f  the  binding  is  being  made  to  a 
-function   de-fined   using   pre-fix  syntax,   the   name   o-f   the 


•function  is  added  to  the  global  PREFIX_OPNAMES.  I-F  an  error 
is  detected  while  evaluating  the  expression  the  message 
'BINDING  CANNOT  BE  MADE'  is  given. 

The  DISPLAY  -Function  looks  at  the  CAR  o-F  the  command 
line  to  continue  the  parse  and  determine  what  must  be 
displayed.  I-f  the  'display'  command  is  used  with  an 
identifier,  the  name  is  looked  up  in  USERDEFS  and  the 
command  that  generated  the  binding  o-f  that  name  is 
displayed.  Otherwise  the  expression  is  evaluated  and  the 
result  is  shown.  The  debugging  commands  illustrated  in  the 
last  three  -forms  in  Figure  V— 3  are  also  handled  by  the 
DISPLAY  -function  (see  section  H  on  I/O). 

D.   EVALUATING  RPL  EXPRESSIONS 

The  heart  of  the  RPL  language  is  the  expression.  The 
expression  is  the  vehicle  that  allows  programmer's  creative 
ability  to  be  transmitted  through  RPL  into  something 
meaningful  to  LISP.  The  process  of  evaluating  these 
expressions  is  centered  around  the  RPL  system  function  Ev- 
This  function,  along  with  several  auxiliary  functions,  parse 
and  evaluate  the  expression  recursively.  The  basic  mechanissTi 
implemented  by  RPL  used  the  design  illustrated  by  MacLennan 
CRef.  5:  chap.  113  and  Winston  CRef.  7:  chap.  231!,  where  a 
LISP  interpreter  was  written  in  LISP,  as  a  model. 

There  a^re  two  main  differences  between  the  design  of  the 
text    book   model   and   the   RPL   system.    Every   operator 


implemented  in  the  model  design  was  in  pre-fix  notation.  RPL 
must  handle  both  infix  and  pre-fix  operators  and  be  able  to 
recognize  in-fix  operators  used  with  pre-fix  syntax.  The  RPL 
system  treats  any  in-fix  operator  as  syntactic  sugar  -for  a 
pre-fix  operator,  which  is  made  explicit  in  the  use  o-f  the 
(op  f)  syntax.  In  this  respect,  the  RPL  system  design  is 
much  more  complex  than  its  model.  Adding  to  RPL ' s  complexity 
was  code  necessary  to  provide  a  robust  interpreter  that 
would  survive  common  programming  errors.  The  error 
detection/recovery  mechanism  is  discussed  separately  in 
section  G. 

The  remaining  section  will  explain  the  design  o-f  the  EV 
■function  and  its  auxiliary  -functions  that  together  provide 
the  mechanism  to  evaluate  the  RPL  expression. 

1  -   The  EV  EyQct i^gn 

EV  is  a  -function  which  was  named  a-fter  the  LISP 
-function  EVAL,  since  -functionally  EVAL  and  EV  Ars  identical. 
Every  expression  in  a  LISP  program  is  sent  to  EVAL.  Every 
expression  in  an  RPL  session  is  sent  to  EV.  EV ,  then,  is  the 
single  most  called  -function  in  the  system.  It  takes  two 
parameters,  a  RPL  expression  and  a  pointer  to  the 
environment  o-f  evaluation,  which  is  the  global  envi  roniTient 
when  called  originally.  Using  indirect  recursion,  EV  and  its 
supporting  -functions  provides  an  e-f-fective  mechanism  which 
is  central  to  the  power  available  in  RPL. 


The  case  analysis  shown  in  Figurs?  V— 4  provides  the 
-framework  -for  the  design  o-f  EV.  The  RPL  expression  is 
represented  in  LISP  as  either  an  atomic  entity  or  as  a  list. 
Both  these  rases  can  each  be  -further  subdivided  into  three 
possibilities.  Using  the  LISP  conditional,  COND,  the  logic 
suggested  in  Figure  V— 4  can  be  encapsulated  into  one 
e-f-ficient  statement.  COND  is  e-f-ficient  since  it  stops 
evaluation  at  the  first  true  statement.  By  care-fully 
ordering  the  possibilities  shown  in  Figure  V— 4  the  number  o-f 
unsuccess-f ul  checks  can   minimized.  The  order  shown  in 

TYPE  EXPRESSION  EXAMPLE  EV  ACTION 

LISP  atomic 

numeric  5  return  5 

string  "hours"  return  "hours" 

literal  avalue  call  LOOKUP 

LISP  list 

special  syntax   ( i -f  p  —  >  -f  ;  g)   call 


ti-^i — o 


length  2  (not  p)  call  PREFIXOP 

length  3  (x  +  y)  call  INFIXOP 

list  w/bar     (f  (,  bar)  g)     call 

EV_SPEC I AL_CASES 

Figure  V'-4  —  Case  Analysis  -for  EV 


Figure  V-4  is  considered  the  most  e-fficient  since  for  every 
call  to  EV  with  a  prefix  or  infix  expression,  which  is  a 
list,  will  require  2  or  3  calls  to  EV  to  evaluate  the 
operator  and  the  operands.  In  most  cases  these  will  all  be 
atoms.  Having  the  atomic  values  checked  first,  since  they 
will  be  the  operand  to  EV  2  or  3  times  more  often  than  the 
lists,  takes  advantage  of  LISP's  implementation  of  the  COND 
f unct i  on . 


A  numeric  or  string  value  sent  to  EV^  is 
immediately  returned  since  these  values  are  the  same  in  RPL 
as  they  are  in  LISP.  The  Literal  atom,  which  is  used  to 
represent  any  o-F  the  RPL  primitive  data  types,  when  sent  to 
EV,  must  be  -found  in  the  environment  so  that  the  value  to 
which  it  is  bound  can  be  returned.  This  value  is  obtained  by 
calling  the  RPL  system  -function  LOOKUP  with  the  variable 
name  and  the  environment  pointer  (see  Figure  V-4)  .  I-f  the 
variable  is  not  -found,  NIL  is  returned  from  LOOKUP,  which 
will  trigger  an  error  in  EV. 

When  the  expression  sent  to  EV  is  a  list  it  may  have 
special  syntax  that  requires  special  handling.  Most  cases 
3.rs  identified  by  a  distinguishing  tag  in  the  grammar:  op', 
'Isec',  'rsec',  etc.  These  tags  are  listed  in  the  global 
variable  SPECIAL_CASES.  I-f  the  CAR  o-f  the  expression  is 
•found  in  the  list  o-f  SPECI AL_CASES  the  expression  is  sent  to 
EV_SPECIAL_CASES  for  evaluation.  Otherwise,  the  length  of 
the  expression  becomes  the  key  to  its  disposition.  This  is 
possible  due  to  the  modifications  that  were  made  to 
'lispify'  the  grammar  (see  Appendices  A  and  B) .  Prefix 
expressions  ar^    of  length  2  from  the  production 

expression  — >  (application  primary), 
while  infix  expressions  are    of  length  3  from  the  production 

expression  — >  (expression  infix  expression). 
With  this  information  EV  can  call  either  PREFIXOP  or  INFIXOP 


to  finish  the  parsing  and  continue  the  evaluation  process  on 
the  expression. 

There  is  one  exception  to  the  method  just  outlined. 
Be-fore  calling  INFIXOP  one  -final  check  must  be  made  for 
special  syntax  to  detect  the  use  o-f  the  'bar'  with  an  in-fix 
operator.  This  syntax  is  used  to  combine  -functions.  The 
following  expression 

(f  (+  bar)  g) 
is  a  function  represented  by 

(closure  x  (  (f  x)  +     (g  x)  )  Ep). 
This  closure  is  created  in  EV_SPECIAL_CASES. 

The  following  subsections  will  illustrate  how  RPL 
internally  translates  an  infix  to  a  prefix  expression,  in 
order  to  maintain  a  single  internal  application  function  and 
provide  a  high  degree  of  user  flexibility.  The  four  step 
mechanism  to  perform  functional  application  will  also  be 
discussed.  The  process  includes: 

(1)  the  evaluation  of  the  actual  parameters 

(2)  binding  the  formal  parameters  to  the  actuals  to  form 
the  local  environment 

(3)  the  addition  of  the  local  environment  to  the 
function's  environment  of  definition  creating  the 
evaluation  environment 

(4)  the  evaluation  of  the  body  of  the  function  in  its 
evaluation  environment. 

This  application  process  is  the  key  to  the  power  of  RPL. 
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2.   Evaluate  Qeerands  -  PREFIXOP  and  INF IX OP 

These  two  -functions  provide  the  next  level  o-f 
parsing  required  to  determine  the  semantics  of  the 
expression.  Both  -functions  are  called  -from  EV  with  a  RPL 
expression  and  an  environment  pointer.  The  operator  and  its 
operands  airs  extracted  and  calls  to  EV  are  made  to  ensure 
operands  3.re  de-fined  and  the  operator  is  de-fined  as  a 
-function.  Completing  these  checks,  the  -first  step  in  the 
application  process  is  accomplished.  Note  that  no  validation 
o-f  operand  compatibility  with  the  operator  is  done  at  this 
time.  I-f  no  errors  have  been  encountered,  the  process 
continues.  This  is  where  INFIXOP  and  PREFIXOP  dicier 
slightly. 

Since  the  expression  in  PREFIXOP  has  the  syntax 
needed  by  the  RPAPPLY  -function,  where  the  application 
process  continues,  no  -further  processing  is  required  in 
PREFIXOP.  However,  since  RPAPPLY  must  handle  both  prefix  and 
infix  expressions,  before  calling  RPAPPLY  INFIXOP  must 
convert  its  operands  into  a  two  element  RPL  list.  Therefore, 
if  L  and  R  a.rs  the  evaluated  arguments  of  the  expression 
originally  sent  to  INFIXOP,  the  parameter  sent  to  RPAPPLY 
will  be  the  equivalent  to  the  RPL  list  (list  L  R) .  This 
would  have  the  follow  internal  representation: 

(  Erel  (1   L)    (2   R)  ) . 
In    summary   both   PREFIXOP   and    INFIXOP   can   be 
considered   preprocessors   for   RPAPPLY.     In   addition,   by 
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evaluating  the  operands,   they  perform  the  -first  step  o-f  the 
■functional  application  process  by  evaluating  the  operands. 

^-   iiD^ing  EeCOl^is  ^Qd  Evaluation  -  RP APPLY 

RPAPPLY  has  one  primary  task,  to  complete  the 
functional  application  process.  To  do  this  it  first  must 
determine  whether  the  function  being  applied  has  been 
implemented  in  LISP  directly  as  part  of  the  RPL  kernel.  The 
kernel  functions  are  readily  distinguished  from  user  or 
built— in  extensional  functions  by  the  length  of  the  list 
containing  the  function's  definition.  For  example  the 
function  '+',  which  is  implemented  in  LISP  directly,  is 
bound  to 

(closure  +) 
in   the   environment.   The  function  DELTA   is   extensi onal 1 y 
defined  and  bound  to 

(closure  x  (list  x  x)  EP) . 
RPAPPLY  passes  all  built-in  functions  that  have  been  coded 
as  part  of  the  kernel  (length  2  closures)  to  BIF_APPLY 
(restrictive  relative  closure).  For  user  and  ex tensi onal 1 y 
defined  functions  RPAPPLY  completes  the  functional 
application  process  recursively  through  EV. 

The  arguments  to  RPAPPLY  are  the  products  of  either 
PREFIXOP  or  INFIXOP.  The  function  and  the  actual  parameters 
have  both  been  evaluated.  To  complete  the  application 
process    the    function's   formal   parameters,    body    and 


environment  pointer  a.re  extracted  -from  its  de-finition 
(closure).  Formals  are  bound  to  the  actuals  by  using  the 
CONS  function  to  create  the  local  environment.  The  number  of 
formal  parameters  must  match  the  number  of  actuals.  If  no 
error  is  detected,  the  local  environment  is  consed  onto  the 
environment  of  definition  creating  the  evaluation 
environment.  With  this  new  environment  the  function  body, 
which  is  a  RPL  expression,  can  be  evaluated.  This  requires 
another  call  on  EV.  Thus  recursion  is  used  indirectly  to 
make  a  very  powerful  evaluation  mechanism. 

The  following  example  demonstrates  the  way  RPAPPLY 
completes  the  functional  application  process.  Suppose 
RPAPPLY  is  called  with  the  following  arguments: 

F  <=   (closure  x  (x  +  1)  Ep-f ) 

A  <=  a 

Since  F  i s  of  length  4,  RPAPPLY  knows  this  is  not  a  LISP 
coded  function.  The  local  environment,  LE ,  is  constructed, 

LE  <=  (CONS  X  8)  =  (x  .  S) . 
The  evaluation  environment,  EE ,  is  constructed, 

EE  <=  (CONS  LE  EP-f)  =  (  (X  .  8  )  EP_f  )  ). 
Now  EV  is  called  to  evaluate  the  body  of  the  function, 

(EV  '  (  X  +  1  )  EE)  . 
4-   iyiltziO  Eyn^tigns  Are  Handled  Bv  BI.F- APPLY 

Of  the  112  RPL  operators,  68  are  coded  directly  in 
LISP.  These  68  functions  form  the  kernel  of  RPL  and  54  Ar& 
handled   in  BIF_APPLY.   The  other  14  operators   have   unique 
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syntax  and  are  handled  in  EV_SPECIAL_CASES.  The  parameters 
to  BIF_APPLY  aire  the  same  as  to  RPAPPLY:  taking  both  a 
■function  and  its  argument  in  evaluated  form.  In  the  case  ot 
in-fix  operators,  operands  have  to  be  extracted  -from  the 
argument  list. 

As  discussed  in  the  previous  section  the  -functions 
which  are  coded  directly  in  LISP  3.rs  bound  to  a  de-finition 
represented  by  a  list  o-f  length  two.  The  second  element  o-f 
this  list  is  used  as  the  key  to  a  very  large  LISP 
conditional.  To  -find  this  key  the  conditional  is  divided 
into  two  logical  parts,  the  built-in  in-fix  operators 
-followed  by  the  pre-fix  built— in  operators.  Since  all  the 
built-in  in-fix  operator  names  Are  listed  globally  in  the 
list  BIFTAG_ir'4FI  X ,  checking  -for  membership  in  this  list 
directs  the  -function  to  the  appropriate  section  of 
the  conditional. 

Once  the  key  has  satisfied  one  of  arms  of  the 
conditional,  operand  compatibility  is  verified.  If  no  errors 
Are  detected  the  code  which  implements  that  operator  is 
executed.  Otherwise,  an  error  handling  mechanism  is 
triggered  which  will  provide  both  meaningful  diagnostics  and 
a  graceful  way  of  unwrapping  the  process  back  to  the  RPL 
command  mode.  RPL  error  handling  is  discussed  in  detail  in 
a  later  subsection. 

This  huge  nested  LISP  conditional  c:a.n  be  considered 
the   end  of  the  line  for  any  recursion  that  might  have   been 
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necessary  through  the  application  process.  The  result  of 
this  function  will  find  its  way  back  to  EV  through  RPAPPLY 
and  either  PREFIXQP  or  INFIXDP. 

5-   Special  Svntax  -  EV_SPECiAL_CASES 

From  an  RPL  programmer's  perspective  RPL  is  a 
language  with  an  enormous  flexibility.  Much  of  the 
programming  power  in  RPL  is  achieved  through  the  use  of 
special  syntax  to  create  programs  mathematically.  Although 
RPL  has  70  operators  implemented  in  the  kernel  and  45 
extensional  ly  defined,  the  language  technically  has  3.n 
infinite  number  of  operators  available  to  the  programmer. 
This  power  and  flexibility  is  achieved  through  special  RPL 
syntax.  EV_SPECI AL_CASES  is  called  from  EV  to  evaluate 
expressions  that  have  the  atom  'func',  'op',  ' 1  sec ' ,  'rsec', 
'if',  'bar'  and  'iter'  in  them.  In  addition, 
EV_SPECI AL_CASES  provides  a  mechanism  to  distinguish  between 
the  input  and  internal  forms  of  sets,  relations  and  RPL 
lists  and  always  returns  the  internal  evaluated  form. 

From  an  implementation  perspective,  EV_SPECI AL_CASES 
became  a  trap  for  cases  that  did  not  really  fit  anywhere 
else  syntactically.  This  was  particularly  useful  in  the 
implementation  of  the  'if'  and  'iter'  operators.  These  both 
return  a  closure. 

The  implementation  strategy  for  all  special  cases 
whose  outcome  was  a  function  was  the  same.  Each  closure  is 
created   by  parsing  the  expression  to  capture  the   semantics 
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o-f   the  expression  within  the  new  body  of  the  new   function. 

The   body   is   another   RPL   eKpression.   For   example,   the 

expression 

(Isec  +  1) 

would  be  translated  into  a  closure  of  the  form 

(closure  ?x  <  ?x  +  1  )  Ep) . 
This  methodology  was  adopted  to  implement  'if'  and  'iter'. 
To  preserve  the  semantics  of  the  original  expression, 
special  syntax  was  introduced  for  the  body  of  the  closure, 
which  would  be  special  cases  not  available  to  the  user. 
Adding  these  expressions  to  the  lists  handled  by 
EV_SPECIAL_CASES  provided  the  facility  to  capture  the 
semantics  of  these  expressions.  The  following  example  t'ji  1  1 
illustrate  the  translation  that  occurs  whenever  'if  and 
'iter'  a.rs    used: 

(if  p  ->  f  ;  g) 
becomes 

(closure  ?x  (  when  (p  7x )  do  (f  ?x )  elsedo  (g  ?x )  )  Ep ) , 
and 

(iter  p  ->  f) 
becomes 

(closure  ?x  (  repeat  f   untilnot   p  )  )  Ep ) . 
By   adding   'repeat'  and  'when'  to  the  list  of  special   case 
tags   these   new   syntax   forms  can   also   be   evaluated   by 
EV_SPECIAL_CASES,   where   they   are    parsed   and   evaluated 
directly  in  LISP.   Note  that  the  'repeat'  syntax  above  shows 
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the  initial  condition  -for  the  iteration.  The  result  o-F 
evaluating  (f  ?x )  becomes  the  agrument  to  'p'-  I-F  the 
predicate  is  true,  'f  '  is  evaluated  with  the  result  o-f  the 
1st  iteration  as  an  argument.  This  process  continues  until 
the  predicate  fails.  The  result  o-f  the  iteration  is  the  last 
value  o-f  (-f  ?M).  This  is  all  done  in  the  REPEAT  RPL 
■function. 

The  rationale  to  create  new  RPL  expressions  +or 
system  use  only  was  so  success-f ul  ,  it  became  apparent  that 
implementation  o-f  other  operators  like  'red',  an  Sirray 
reduction  operator,  could  use  the  same  convention.  Since 
'red'  is  an  in-fix  operator  and  has  no  special  syntax,  a 
slight  conceptual  problem  o-f  where  to  create  the  closure 
emerged.  All  closures  that  were  -formulated  thus  ra.r  were 
done  in  EV_SPECIAL_CASES ,  but  these  came  -from  cases  having 
special  syntax.  Since  the  'red'  operator  had  no  special 
syntax,  it  was  inappropriate  to  create  the  closure  in 
EV_SPECIAL_CASES.  To  be  consistent  with  the  design,  the 
closure  was  created  in  BIF_APPLY.  However,  in  -formulating 
the  body  o-f  the  closure  a  special  syntax  is  used  which  can 
be  identi-fied  and  evaluated  readily  by  EV_SPECI AL_CASES.  The 
closure  created  -for  this  operator  is  illustrated  by  the 
following  example:  the  expression 

(f  red  i) 
becomes 

(closure  ?A  (  reduce  ?A  by  f  from  i  )  Ep ) . 
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Another  choice  o-F  implementation  would  still  result 
in  the  -final  evaluation  in  EV_SPECIAL_CASES  but  v-^ould 
eliminate  a  call  to  BIF_APPLY.  Since  what  is  actually  hard 
coded  in  LISP  is  the  function  ARRAY_REDUCTIDN,  the  'rsd' 
operator  could  be  de-fined  extensional  ly  in  terms  o-f  the 
special  syntax  and  take  advantage  o-f  the  bindings  created  by 
RPAPPLY.  For  example,  i -f  the  'red'  operator  were  defined 

red  ==  (func  (f  i)  (func  ?A  (reduce  ?A  by  f  from  i))) 
or 

f  red  i  ==  (func  ?A  (reduce  ?A  by  f  from  i)) 
the   call  to  EV  from  RPAPPLY  with  'red'  and  the   environment 
Ep  would  produce  the  same  results  as  what  was  accomplished  by 
BIF_APPLY.   However,   this  implementation  would  require   the 
error   checking  now  done  in  BIF_APPLY  to  be  shifted  into  the 
function   ARRAY_REDUCTION. 

Tracing  the  evaluation  of  the  ex tensi onal 1 y   defined 
'red'  shows  the  subtle  differences  between  implementations. 
Given  the  expression 

(  f '  red  i  '  )  , 
EV  recognizes  the  infix  expression  and  calls  INFIXOP,   where 
the   'red'   is  evaluated.   The  current  implementation   calls 
BIFAPPLY  since  the  evaluated  form  of  'red'  is 

(closure  reduction). 
However,   in  the  ex tensi onal  1  y  defined  implementation    red' 
is  bound  to 

(closure  (f  i)  (func  7A  (reduce  ?A  by  f  from  i))  Ep ) . 


In  the  current  implementation  BIF_APPLY  is  called  to  -finish 
the  application  process  directly  in  LISP,  whereas  the 
alternate  implementation  uses  the  mechanism  provided  in 
RPAPPLY.  The  -formals,^  and  i,  are  bound  to  the  actuals  f' 
and  i'.  The  evaluation  environment  is  created  and  EV  is 
called  to  complete  the  process  with  the  expression 

(■func  ?A  (reduce  ?A  by  f  -from  i)  EE)  . 
The   '-func'  tag   directs  the  expression  to   EV_SPECIAL_CASES 
where  the  closure  is  created. 

The  di-f-ference  in  implementation  e-f-ficiency  can  be 
studied  by  using  the  LISP  -function  BREAKDOWN.  Currently  the 
composition  and  paralleling  operator  ^re  defined  using  the 
'-func'  construct  as  extensi  onal  s. 

F.   EXTENSIONAL  MECHANISM 

Almost  hal-f  the  operators  in  RPL  have  been  implemented 
extensional 1 y .  The  operators  directly  coded  in  LISP  either 
were  listed  as  primitive  operations  by  MacLennan  CRe-f.  2j  or 
had  a  -function  readily  available  in  LISP  i*/hich  would 
hope-fully  provide  a  more  e-f-ficient  implementation  than  the 
extentional  de-finition.  The  purpose  o-f  this  section  is  to 
discuss  the  mechanism  which  the  system  uses  to  implement  an 
extensional  operator. 

The  ex  tenti  onal  1  y  de-fined  operator  is  executed  by  the 
RPL  system  taking  advantage  of  the  same  mechanism  that  is 
in  place  to  bind  user  de-fined  -functions.  When  RPL  is  called, 
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a-fter  all  the  globals  have  been  initialized,   (see  Figure  V— 
5),  the  system  is  ready  to  de-fine  the  extensional  operators. 

During  initialization  the  environment  contains  all  the 
built  — in  operators  which  ars  coded  in  LISP.  These  a.re 
represented  by  a  length  2  closure  as  discussed  earlier  in 
this  chapter.  At  this  time  commands  can  now  be  accepted  by 
the  system.  All  the  extensional  ly  de-fined  operators  bt^ 
contained  in  a  list  as  RPL  commands.  This  list  is  called 
INTOPS.  Using  a  the  LISP  -function  MAPCAR,  all  extensional 
commands  ars  sent  to  EXECUTE  and  ultimately  bound  to  the 
environment.  A-fter  the  last  extensional  operator  has  been 
de-fined  the  system  ready  -for  the  user. 

Implementing  this  mechanism  was  straight  -forward  but 
there  were  some  varibles  that  had  to  reset  be-fore  the  user 
was  given  control  o-f  the  system.  These  arB  shown  in 
Figure  V— 5. 

The  interesting  part  o-f  this  implementation  was  the 
ability  to  try  each  o-f  these  operators  during  RPL  sessions 
prior  to  committing  them  into  the  list  o-f  extensi  onal  s. 
Since  some  extensi onal s  were  built  on  others,  the  order  that 
these  were  actually  de-fined  was  si  gni -f  i  cant .  This  was  due  to 
static  scoping.  There-fore,  some  car&  had  to  be  used  when 
adding  new  de-finitions  to  INTOPS.  Future  research  may  try 
coding  some  o-f  the  extensi  onal  s  o-f  this  impl  ementai  on  into 
LISP  directly  and  do  a  per-formance  analysis  using  BREAKDOUJN. 
This  will  be  discussed  in  more  detail  in  Chapter  VII. 
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NAME  /  INIT  VALUE 

BIFTAG_INFIX 
/  list  o-f  names 

BUILT_IN_PREFIX_OPS 
/   list  o-f  names 


CHANGED  BY 
N/A 

N/A 


PURPOSE 

Control  -flow  in 
BIF_APPLY 

Resets 

PREFIX  OPNAMES 


/  SYSQPS 


DEF_BINDING 
EXIT 


Global  environment 


EMSG 
/  list  o^^  msgi 

ERRORCODE 
A  ERRORFREE 


N/A 


Table  o-f  error 
messages 


ERROR  HANDLER   Error  recovery 


F I LTER_ON 
/  NIL 

I NTOPS 
/  list  o-f  commands 

NUMOP 
/  list  of  operators 

OPNAMES 
/  1  i  st  o-f  names 

PREFIX_OPNAMES 
/  BUILT  IN  PREFIX  OPS 


FILTER 


N/A 


N/A 


N/A 


DEF_BINDING 
EXIT  (reset) 


Switch  o-f-f  error 
msgs  while  -filtering 

All  extensional 
operator  de-f  i  ni  t  i  ons 

Control  -flow  in 
BIF_APPLY 

Check  to  avoid 
renaming  built-in  opi 

Error  checking 
-for  '  op  '  ,  '1  sec  ^ 
' rsec ' 


SETS 
/  list  o-f  input  tags 

3ET0PS 
/  list  o-f  operators 

SYSOPS 
/  1 i  st  bui 1 t-in 
operators 

SYSTEM_ENV 
/  E 

USERDEFS 
/  NIL 


N/A 


N/A 


N/A 


N/A 


DEF_BINDING 
EXIT  (reset) 
RPL  (reset) 


Control  -flow  in 
EV_SPEC I AL_C ASES 

Control  -flow  in 
BIF_APPLY 

Kernel 


To  reset  E  when 
clearing  environment 

di  spl ay 

WRITE  USER  DEFS 


Figure  V-5  —  Alphabetic  Global  Listing 
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G.   ERROR  DIAGNOSTICS  AND  RECOVERY 

The  primary  consideration  -for  performing  error  checking 
in  the  RPL  interpreter  was  to  ensure  the  system  would 
survive  common  programming  errors.  I-f  every  minor  mi  scus 
were  to  cause  the  RPL  system  to  crash  errors  like  undefined 
variables,  improper  arguments  to  built— in  and  user  de-finsd 
functions,  syntax,  spelling  and  typographical  errors,  each 
could  cause  a  major  catastrophy,  costing  many  hours  of  work 
and  added  programmer  frustration.  Surely  a  system  without 
safeguards  to  prevent  self  destruction  would  be  impossible 
to  work  with,  even  in  a  prototype  implementation.  Therefore, 
one  of  the  major  design  decisions  in  the  development  of  the 
interpreter  was  to  make  the  RPL  system  as  robust  as  possible 
and  provide  meaningful  diagnostics  to  the  user. 

1 .   Error  Recover v 

LISP'S  built-in  functions  ar^  not  unlike  those  found 
in  any  other  language;  improper  operands  3.rs  generally  a 
disaster.  A  keen  awareness  of  this  problem  had  to  be 
developed  to  ensure  sufficient  type  checks  were  accomplished 
so  that  user  inputs  could  not  create  an  unrecoverable 
situation.  Although  Interlisp  does  provide  a  means  of  error 
recovery  through  its  debugging  facilities,  this  is  only  a 
benefit  to  the  user  who  has  had  sufficient  experience  with 
the  Interlisp  break  commands  (see  Teitelman  CRef.  6D  for 
more  details).  Therefore,  it  was  necessary  to  build  into  the 
RPL   system  a  self-contained   capability  that  could   detect, 
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diagnose  and  resume  operation,   totally  independent  -from  the 
LISP  error  handling  mechanism. 

Once  an  error  is  detected,  the  RPL  system  calls  its 
error  handling  -function  with  two  parameters.  The  -first 
parameter  i s  an  error  code,  which  is  used  as  an  index  to  a 
table  o-f  error  messages.  The  second  parameter  is  the  cause 
of  error.  The  error  handler  prints  the  appropriate  error 
message  and  cause  of  error,  and  assigns  to  the  global 
variable  ERRORCODE  the  value  of  the  first  parameter. 
ERRORCODE  is  always  initialized  to  ERRORFREE  before  a 
command  is  entered  by  the  user.  Finally,  the  value  returned 
by  the  error  handler  is  the  LISP  atom  NIL. 

Checking  the  value  of  ERRORCODE  in  strategic  areas 
throughout  the  program  prevents  both  redundant  error 
messages  and  meaningless  operations.  For  example,  in  the 
process  of  evaluating  a  prefix  expression  both  the  operator 
and  the  operand  must  be  evaluated  separately  to  ensure  they 
Ar-B  defined.  If  any  errors  a.re  encountered  in  this  process 
the  remaining  code  in  the  prefix  expression  parse  c.3.n  be  by- 
passed by  checking  the  value  of  ERRORCODE  before  preceding. 

The  value  of  ERRORCODE  is  checked  before  any 
bindings  ar&  made  to  the  RPL  environment.  If  ERRORCODE  is 
not  ERRORFREE  the  message  'Binding  cannot  be  made'  is  given. 

The  value  of  the  functions  that  parse  either  prefix 
or  infix  expressions  each  return  NIL  if  an  error  occurs.  In 
the  RPL  DISPLAY  function,   if  the  LISP  value  NIL  is  returned 
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-from  evaluating  an  expression,   the  message  'Undefined'  v*ji  1 1 
be  displayed. 

Calls  to  the  error  handler  and  the  inspection  o-f  the 
value  o-f  ERRORCODE  is  interwoven  throughout  the  RPL  system. 
This  was  impossible  to  avoid,  if  the  RPL  system  was  to  have 
the  degree  o-f  resiliency  desired.  To  change  the  basis  o-f  the 
error  handling  mechanism  used  would  certainly  take  a 
considerable  amount  o-f  receding.  This  should  be  unnece-ssary 
due  to  the  excellent  recover abi 1 i ty  shown  in  the  RPL  system 
during  testing. 

2.   RPL  Di_agngsti_c5 

RPL  su-f-fers  -from  a  problem  prevalent  among  many 
extensible  languages,  its  diagnostics  Are  sometimes 
meaningless.  This  is  because  error  checking  is  per -formed  on 
the  operands  o-f  the  -functions  de-fined  in  the  kernel  of  the 
language.  The  kernel  is  a  set  of  functions  from  which 
additional  features  ars  implemented.  The  diagnostics  related 
to  calls  on  these  functions,  V'jhen  used  explicitly  by  the 
user,  a.re  helpful  and  descriptive.  These  same  diagnostics, 
when  given  to  a  user  who  is  invoking  a  function  defined  in 
terms  of  the  kernel,  may  be  of  little  ar    no  value. 

The  diagnostics  displayed  when  an  error  is 
discovered  while  performing  a  domain  restriction  illustrate 
a  situation  where  the  system  can  provides  accurate  but 
confusing  diagnostics.  The  operator  '->'  is  defined  directly 
in  terms  of  the  RPL ' s  'filter'  operator  as  follows: 
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p  ->  t  ==  ((p  o  hd>  filter  t). 
The   composition   operator  'o'  is  de-fined  using   the   -formal 
parameters  -f  and  g  as  -follows: 

o  ==  (func  (-f  g)  (-func  x  (-f  (g  >;)))). 
A   user   who   is  un-f  ami  liar  with   these   dependencies   would 
certainly   find  diagnostics  in  terms  of  p,   t,   f  or  g  quite 
puzzling    if   he   had   never   bound   these   names   in    his 
ens'i  ronment . 

The  more  familiar  that  one  becomes  with  the  RPL 
system  and  the  various  extended  functions,  the  more 
meaningful  the  diagnostics  will  become.  When  given 
diagnostics  that  appear  totally  unrelated  to  what  was  input 
as  an  RPL  command,  there  is  an  excellent  possibility  that  an 
extended  operator  is  being  used.  Probing  the  environment 
with  some  of  the  features  added  to  RPL  as  a  troubleshooting 
aid  (env,  val  and  env  f)  v^*i  1 1  help  put  more  meaning  into 
error  diagnostics,  and  enable  the  user  to  better  understand 
the  RPL  language. 

3.   EI1C2IZ5  Can  Be  Easi^l^y  lyilt  I.n 

The  incompatibility  between  functions  and  their 
arguments  referred  to  thus  far  Are  a  direct  result  of  user 
errors.  Guarding  against  this  kind  of  circumstance  was  only 
part  of  the  problem  encountered  to  make  RPL  robust.  ExtreiTie 
iZArs  had  to  be  taken  not  to  build  potential  fatal  errors 
into   the   interpreter.   This  became  apparent  as  the   system 
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crashed  in  areas  originally  thought  to  be  sound,  during  some 
o-f  the  earlier  RPL  system  tests. 

As  discussed  in  Chapter  III,  the  -functions  CAR  and 
CDR  3ire  used  to  access  various  elements  ot  a  list.  Like  any 
other  -function,  these  -functions  a.re  designed  for  a  specific 
type  of  operand.  Calling  either  function  with  a  non-list 
creates  a  fatal  error.  The  system  was  vulnerable  to  this 
situation  in  the  original  coding.  To  prevent  this  type  of 
error,  each  time  the  CAR/CDR  functions  appeared  in  the 
development  of  the  interpreter,  a  list  check  and/or  length 
check  had  to  performed  before  proceeding.  The  code  used  to 
implement  the  type  checking  function,  TYPE,  for  the  RPL 
system  indicates  the  caution  needed  when  using  these 
functions.  This  is  also  evidenced  the  use  of  compound 
statements  in  many  LISP  conditionals,  where  the  AND 
statement  first  performed  a  list  check  and  then  a  length 
check  before  using  the  CAR  or  CDR  functions. 

Achieving  the  goal  of  making  RPL  robust  involved 
much  more  than  an  exercise  in  anticipating  user  errors.  It 
also  required  a  conscientious  analysis  of  every  aspect  of 
the  interpreter  to  determine  what  inputs  or  results  could 
create  disaster.  Testing  thus  far  has  shown  that  this  goal 
has  been  essentially  achieved. 
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H.    INPUT  /  OUTPUT 

The  input/output  -functions  needed  by  the  RPL  system  can 
be  logically  divided  into  two  categories,  console  10  and 
-file  10.  Console  10  functions  provide  a  mechanism  to  input 
RPL  commands,  display  the  results  o-f  evaluating  RPL 
commands,  provide  error  messages  and  prompt  the  user  for 
input.  The  file  10  functions  provides  both  a  facility  to 
execute  the  RPL  'file'  operator  and  gives  the  user  the 
ability  to  save  and  recall  his  RPL  sessions. 
1 .   Cgnsgl_e  iDgut /Out gut 

The  primary  consideration  for  altering  normal  LISP 
ID  originally  was  the  aesthetic  desire  to  eliminate 
parentheses  not  absolutely  essential  to  parsing  and  command 
execution.  This  is  achieved  through  masking  some  of  the 
required  input  parentheses  and  filtering  meaningless 
parentheses  during  output.  This  eliminated  some  of  the 
awkward  syntax  that  had  been  introduced  in  order  to  use  LISP 
as  an  implementation  language  (see  Why  LISP  Chapter  III).  As 
the  interpreter  developed,  a  far  more  important  reason  for 
filtsring  console  output  was  realized. 

The  only  relief  from  the  LISP  syntax  during  terminal 
input  was  achieved  by  the  elimination  of  the  outer  set  of 
parentheses  from  the  RPL  command  line.  This  was  accomplished 
through  the  use  of  the  Interlisp  READLINE  function.  This 
function  inserts  parentheses  around  a  line  of  input  which  is 
terminated   by   a   carriage  return  or       the   character   ']'. 
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Additionally,   the   READLINE  command  provides  a  mechanism  to 
enable  the  user  to  know  when  all  open  parentheses  have   been 
closed.  This  is  illustrated  in  the  -following  example. 
I-f   the  user  wants  to  type  the  command 

(-f  X  ==  (x  +  1)  )  , 
the  READLINE  -function  would  allow  it  to  entered  as  -follows: 

-f  X  ==  (X  +  1). 
When   the  user  types  the  closing  parenthesis  a-fter  the    1', 
the  the  -following  would  be  displayed: 

-f  X  ==  (x  +  1) 

■  «  ■ 

The  •'...'  indicates  all  parentheses  have  been  closed.  A 
carriage  return  at  this  point  will  enter  the  command  -for 
execution.  Since  every  RPL  expression  must  be  enclosed  in 
parentheses,  this  -feature  is  particularly  helpful  to  the 
programmer. 

To  'delispi-fy'  RPL  output,  user  prompts  and  error 
messages  were  printed  by  a  function  written  to  filter 
parentheses  by  printing  lists  one  atom  at  a  time,  using  the 
very  fast  and  efficient  LISP  MAPCAR  function.  This 
methodology  was  originally  used  for  all  RPL  output,  but  had 
to  be  restricted  to  prompts  and  messages.  This  restriction 
was  necessary  since  the  way  lisp  prints  a  list  proved  to 
unsuitable  for  printing  the  internal  definition  o-f  a 
function.  This  problem  was  encountered  printing  output  from 
the  RPL  'display'  command. 


The  method  chosen  to  internally  represent  -functions 
made  displaying  them  on  the  screen  impractical  and  in  some 
instances  impossible. 

As  discussed  in  Chapter  V,  each  -function  that  is 
either  user  de-fined  or  built  — in  as  an  extension  o-f  the  RPL 
kernel,  has  associated  with  its  name  the  keyword  'closure', 
its  -formal  parameters,  its  body  and  its  environment  o-f 
de-finition.  This  environment,  which  is  represented  as  a 
pointer  to  an  a-list  in  LISP,  includes  all  RPL  built— in 
-functions  along  with  all  names  and  -functions  defined  by  the 
user  up  to  time  the  -function  was  de-fined.  Printing  this 
environment  had  to  avoided.  This  was  accomplished  by 
creating  two  integrated  -functions,  PRINT_LIST  and  SHOW_ATOM, 
to  screen  all  RPL  output,  trapping  all  -functions  so  that  the 
environment  could  be  truncated  -for  console  output. 

To  maintain  the  user  s  ability  to  inspect  the 
environment,  some  additional  features  had  to  be  added  to  the 
RPL  system.  This  resulted  in  a  minor  modi -f  i  cat  i  on  to  the 
grammar  and  the  addition  o-f  the  -function  SHOW_ENv.  For 
example,  typing  'env'  provides  a  list  o-f  all  names  with 
their  respective  internal  definitions  that  ^re  within  the 
environment  created  by  the  user.  Each  function,  of  course, 
would  be  shown  without  its  environment  of  definition.  To 
display  the  environment  of  definition  associated  with  a 
given  function  f,  the  command  'env  f '  is  used. 
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Two   additional  -features  were  also  added  that   allow 
the   user  to  view  either  the  internal  definition  ,  associated 
with  a  name  or  his  original  input  form.  This  is  discussed  in 
more  detail  in  Chapter  VI. 
2.   Eiie  Inout/QutByt 

There  are  two  sets  o-f  -file  10  -functions  used  within 
the  RPL  system.  The  -first  set,  consisting  o-F  the  -functions 
FILE_READ  and  FILE_WRITE,  is  used  to  implement  the  RPL 
'-file'  operator.  The  second  set,  added  as  a  user  convenience 
to  provide  a  mechanism  to  save  and  recall  RPL  sessions,  is 
comprised  o-f  the  -functions  SET_USER_ENV ,  READ_USER_DEFS , 
EXIT  AND  UJRITE_USER_DEFS.  Both  sets  o-f  file  10  functions 
utilize  the  Interlisp  file  package  commands  to  access  or 
initialize  a  file,  perform  desired  10  and  close  the  file. 

RPL '  s  'file'  operator  is  designed  to  read  or  write 
data  in  its  evaluated  form.  This  data  is  usually  a  set  or 
table.  This  operator  should  never  be  used  with  functions, 
either  directly  or  indirectly,  embedded  within  a  set.  This 
would  cause  the  function's  entire  environment  of  definition 
to  be  written  to  a  file  as  a  list,  one  atom  at  a  time. 
Reading  a  function  from  a  file  that  was  written  in  evaluated 
form,  not  only  may  be  impossible  due  to  insufficient  memory, 
but  obviates  the  efficiency  of  the  environment  mechanism. 
RPL  was  designed  to  have  only  one  a-list  represent  its 
environment.  A  function's  environment  of  definition  is  just 
a  pointer  to  a  node  within  the  RPL  system  environment. 
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In  a  typical  RPL  session  a  user  may  have  a 
considerable  amount  o-f  time  invested  constructing  numerous 
■functions  and  data  definitions.  As  a  command  is  entered 
that  binds  a  name  to  the  RPL  environment,  the  command  is 
saved  in  a  separate  list  that  can  be  written  to  a  -file.  UJhen 
read  back  into  RPL,  the  system  executes  each  command,  thus 
recreating  the  previous  session. 

The  user  has  the  flexibility  to  modify  or  create 
files  using  any  available  editor.  His  only  constraint  is  to 
ensure  the  string  EOF  appears  as  the  last  line  of  the  file. 
The  EOF  string  is  automatically  written  to  all  sessions 
saved  i  n  RPL . 

Interlisp  operating  on  UNIX  provides  a  means  to  save 
old  versions  of  files  as  new  files  a.re  created-  The  updated 
file  will  have  its  file  name  modified  to  indicate  the  next 
version  number.  Since  UNIX  only  recognizes  unnumbered  names, 
each  updated  file  created  by  Interlisp  contains  two 
directory  entries,  one  numbered  and  one  unnumbered. 
Interlisp  provides  the  mechanism  to  manipulate  older 
versions  CRef.  S:  p.  111. 
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VI.   USING  IHE  RPL  INIERPRETER 

A.  INTRODUCTION 

The  RPL  language  is  di-F-ferent  -From  any  conventional 
language  that  currently  exists.  Because  o-f  its  uniqueness, 
inherent  power,  and  mathematical  base,  it  can  be  di-f  +  icult 
to  use  at  first.  But,  as  with  any  other  language,  it  can  be 
mastered  through  a  study  o-f  the  underlying  concepts  and 
hands  on  experience  with  the  commands.  This  chapter  will 
describe  the  basic  knowledge  required  to  use  the  prototype 
RPL  interpreter  developed  in  this  research.  It  will  only 
touch  upon,  through  simple  examples,  the  power  o-f  such  a 
language.  Only  the  dedicated  e-f -forts  o-f  an  innovative  user 
will  test  the  system  and  discover  the  real  potential  o-f  the 
relationa^l  programming  concept. 

B.  GETTING  STARTED 

The  RPL  interpreter  exists  as  a  Unix  file  which  consists 
of  77  LISP  functions  which  implement  the  RPL  grammar  shown 
in  Appendix  B  and  the  relational  operators  described  in 
Appendix  C.  To  invoke  the  RPL  interpreter,  a  user  must 
first  have  a  basic  knowledge  of  the  Unix  Operating  System. 
He  must  at  a  minimum  be  able  to  log  on  with  access  to  an 
account  which  contains  the  'RPL-INT'  file.  For  more 
information  on  the  Unix  Operating  System,  see  reference  3. 
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When  the  Uni>;  prompt  {'/.)  appears,  the  next  step  is  to 
enter  the  Interlisp  environment,  which  provides  a  shell  -for 
RPL.  Since  the  interpreter  is  written  in  LISP,  -familiarity 
with  its  basic  constructs  is  desirable,  and  a  necessity  i -f 
one  is  going  to  explore  the  LISP  code  -for  the  interpreter 
itsel-f.  See  re-ferences  5,  6  and  7  -for  more  in-formation 
about  LISP  and  the  Interlisp  environment. 

Loading  the  Interlisp  environment  is  accompanied  by  a 
substantial  delay,  but  when  the  environment  is  -finally 
loaded,  it  gives  the  user  a  -friendly  greeting  to  let  him 
know  it  is  ready  to  accept  commands.  The  only  LISP  command 
that  must  be  used  is  'LOAD'  which  loads  a  -file(s)  o-f  LISP 
functions.  There-fore,  at  the  LISP  prompt,  '_',  the  user 
must  type  ' LOADCRPL-INTD ' .  When  the  closing  bracket  is 
typed  Interlisp  will  automatically  execute  the  command. 
Interlisp  searches  the  user's  directory  for  this  file  and, 
when  it  is  found,  displays  a  message  indicating  the  date  the 
file  was  created.  Once  loaded,  another  Interlisp  prompt 
will  be  displayed.  Now  all  the  functions  necessary  to 
execute  RPL  commands  Ar^  part  of  the  Interlisp  environment, 
but  of  no  use  to  the  programmer  until  he  invokes  the  RPL 
interpreter  itself. 

All  commands  in  LISP  a.r&  enclosed  in  parentheses  or 
brackets.  Just  as  the  keyword  ' i 1 i sp '  triggers  the  Unix 
system  to  load  the  Interlisp  environment,  the  LISP  function 
'RPL'   initializes  and  loads  the  RPL  environment  on   top   of 
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Interlisp.  Thus  to  begin  an  RPL  session  the  LISP  command 
'CRPLH'  is  typed  at  the  LISP  prompt.  Once  this  command  is 
executed,  the  user  will  enter  and  remain  in  the  RPL 
environment  until  the  RPL  command  'done'  is  executed.  (See 
section  I  -For  exceptions). 

When  the  initialization  required  by  the  RPL  interpreter 
is  completed  the  user  is  asked  if  he  wishes  to  reBu/rse  a 
previous  RPL  session.  This  gives  the  programmer  the  option 
o-F  having  a  -File  o-F  RPL  de-Fi  nit  ions  executed  that  was 
created  either  -From  within  RPL  or  by  an  external  text 
editor.  Caution  is  advised  i -F  the  -File  was  created  by  an 
external  editor  since  no  error  checking  will  be  done  until 
loading  such  a  session  -For  the  -First  time.  If  there  is  a 
parenthesis  out  of  place  or  missing,  it  could  throw  the  user 
out  of  RPL  and  into  the  LISP  error  handler.  Some  other 
dangers  Ars    discussed  in  section  I  of  this  chapter. 

If  the  user  answers  'yes'  he  will  be  prompted  for  a 
filename.  It  is  appropriate  to  mention  at  this  point,  that 
an  inconvenience  exists  due  to  the  limited  control  over 
input /output  by  the  interpreter.  When  a  response  is 
required,  or  a  command  is  entered,  the  first  character  typed 
is  fixed,  i.e.,  it  cannot  be  removed  from  the  input  buffer. 
All  characters  after  the  first  one  can  be  altered  as 
required  until  a  input  termination  signal  is  sent.  In  the 
RPL  environment,  hence  the  Interlisp  environment,  this 
signal   is  a  carriage  return  or  a  final  closing   parenthesis 
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or  bracket.  Thus  if  the  user  makes  an  error,  -For  whatever 
reason,  and  the  -filename  is  not  in  his  directory,  RPL  will 
inform  the  user  that  the  file  was  not  found  and  continue  on. 
The  only  avenue  open  to  the  user  if  this  happens,  is  to 
terminate  the  session  and  begin  again.  This  is  not  as  bad 
as  it  may  sound,  as  the  next  section  will  point  out. 

If  the  file  does  exist,  RPL  will  load  and  execute  all 
commands  in  the  file,  and  prompt  him  for  his  first  RPL 
command.  Figure  VI-1  and  Figure  VI— 2  illustrate  the  command 
sequence  which  would  load  RPL  with  and  without  a  previous 
session,  respectively. 

C.   SESSION  TERMINATION 

When  the  user  is  finished  with  a  session  he  types  the 
command  'done'.  This  command  triggers  a  series  of  options 
available  to  the  user.  First,  he  will  be  asked  if  he  wishes 
to  save  the  session  just  completed.  If  the  answer  is  yss  he 
will  be  prompted  for  a  filename.  RPL  will  write  all 
commands  executed  in  the  session,  in  their  original  input 
form,  to  that  file.  'Display'  commands  a.rs    not  included. 

Regardless  of  his  answer  to  the  first  question,  the  user 
is  then  given  three  options:  exit  to  the  Inter lisp 
environment,  exit  to  the  Unix  Operating  System,  or  begin 
another  RPL  session.  If  he  chooses  to  begin  another  ses-sion 
he  will  be  asked  if  he  V'^ants  the  current  environment  from 
the  session  he  is  leaving  to  be  cleared.    After   completing 
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I   ilisp 

I3I-INTERLISP  15-MAY-84  ... 


Hi. 

.LOADERPL-INT] 
File  Created:  12-1* 
RPL-INTCOMS 


-95  10:03:30 


expanding  LISTP,  65523  used,  2424832  before  BC 

/work/brown/RPL-INT 

_[RPL] 

Loading  RPL—  DO  YOU  WANT  TO  RESUME  A  PREVIOUS  RPL  SESSION^  <y/n>  y 

INPUT  FILENAHE 

ses5512 

Loading —  Session  loaded 


RPL  INTERPRETER  ON  LINE." 
?>  d  (2  +  3) 
5 

Figure  VI-1  —  Loading  the  RPL  Interpreter,  tilth  Previous  Session 
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the  action  required  by  the  user's  response,  the  RPL 
interpreter  begins  the  same  cycle  as  i-f  the  user  was 
beginning   a  new  session.    This  cycle  continues   until   the 


I   ilisp 

ISI-INTERLISP  15-HAY-e4  ... 

Hi. 

.LOAD[RPL-INT] 

File  Created: 12-«AY-85  10:33:33 

RPL-INTCOtIS 

expanding  LI3TP,  65523  used,  2424832  before  SC 

/work/brown/RPL-INT 

.[RPU 

Loading  RPL—  DO  YOU  WANT  TO  RESUME  A  PREVIOUS  RPL  SESSION?  <y/n>  n 


RPL  INTERPRETER  ON  LINE" 
?>  sqr  X  ==  (k  times  x) 
?> 

Figure  VI-2  ~  Loading  the  RPL  Interpreter,  Without  Previous  Session 

user  decides  to  completely  exit  the  RPL  environment. 
Figure  VI— 3  illustrates  a  session  termination  sequence  where 
the  user  wishes  to  remain  in  the  RPL  environment. 
Figure  VI-4  shows  a  user  termination  with  exit  to  the  Unix 
Operating    System. 

D.        EXECUTING    COMMANDS 

RPL    commands    Are    derived    from    the    grammar    in    Appendix    B. 
It  allows       for       three       basic       types       of  commands:  data 
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!      ?>  done 

!      DO  YOU  «ANT  TO  SAVE  ENVIRONMENT  FOR  FUTURE  USE^ 

<y/n>  y 

!      INPUT  FILENAHE 

1        5655525 

!      EXIT  TO  LISP  - 

PRESS  'D 

I      EHT  TO  UNIX  - 

PRESS  -t 

!      CONTINUE  RPL  - 

PRESS  < RETURN) 

!      DO  YOU  WANT  TO  CLEAR  CURRENT  ENVIRONHENT^  <y/n> 

y 

!      DO  YOU  WANT  TO  RESUME  A  PREVIOUS  RPL  SESSION?  <■ 

•7n>  n 

9> 

Figure  VI-3  ~  Session  Tersination  -  Reaiain  in  RPL 


!      ?>  done 

1      DO  YOU  WANT  TO  SAVE  ENVIRONMENT  FOR  FUTURE  USE^  <y 

'n>  y 

1      INPUT  FILENAHE 

1      ses5525-l 

!      EXIT  TO  LISP  -  PRESS  ^D 

!      EXIT  TO  UNIX  -  PRESS  'C 

CONTINUE  RPL  -  PRESS  <RETURN> 

I   logoff 

!       Signing  off... 

Figure  VI-4  ~  Session  Teraination  -  Exit  to  Unix 
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definitions,  function  definitions,  and  input/output.  The 
sections  following  this  one  will  -describe  how  to  enter  the 
commands  of  each  type  and  provide  a  brief  discussion  of  the 
built-in  relational  operators.  This  section  will  provide 
some  general  information  and  guidance. 

RPL  operators  and  commands  Are  case  sensitive.  Since 
most  operators  and  all  commands  are  in  lowercase,  it  is 
recommended,  though  not  required,  to  use  lowercase  letters 
throughout  an  RPL  session.  Lowercase  was  used  to  help 
distinguish  the  operators  and  commands  from  LISP  function 
names,  which  Are  capitalized.  Any  variation  at  the  keyboard 
will  cause  RPL  to  return  an  error. 

E.   DATA  DEFINITIONS 
1 .   Iq  troduc  t  i^gn 

There  Are  several  data  types  available  to  RPL.  In 
addition  to  the  normal  scalar  types,  integers,  reals, 
booleans  and  strings,  there  Are  sets  and  relations.  Sets 
and  relations  can  be  used  to  represent  any  conventional  data 
structures  such  as  arrays  and  records-  They  can  also  easily 
represent  more  complex  structures  such  as  matrices, 
databases,  trees  and  graphs.  A  relation  is  actually  a 
special  form  of  set  where  each  element  must  be  a  pair  of  RPL 
data  types.  The  tremendous  flexibility  of  the  relation 
results  because  this  pair  can  be  any  combination  of  RPL  data 
types. 
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RPL   syntax   allows   the  binding  o-f  a   name   to   any 
scalar  type  directly.   For  example: 

X  ==3 
error  ==  true 
name  ==  "John" 

The  '=='  symbol  in  RPL  means  'de-fined  as'. 

2.  Sets 

A   set  is  defined  simply  by  placing  the   keyword 
'set'  as  the  -first  element  of  the  set.   For  example: 

aset  ==  (set  1  2  "dog"  colors] 
The  '  II  '  symbol,  used  to  close  the  defintion,  keys  the 
interpreter  to  execute  the  command.  This  aspect  of  the 
command  line  will  be  discussed  further  in  section  G.  Note 
the  name  colors  must  have  been  previously  defined  or  an 
error  will  result.  In  this  case,  colors  may  have  been 
defined  as: 

colors  ==  (set  "red"  "white"  "blue": 
This  illustrates  that  each  element  of  a  set  can  be  anything, 
even  another  set. 

3.  R^i.^ti_ons 

Any   relation   can   be   defined   in   RPL   using   the 
following  syntax: 

r  ==  (rel  (XI  :  YD  (X2  :  Y2)  ...  (Xn  :  Yn)] 
The  X's  and  Y's  can  be  any  RPL  data  type.   The  ': '  symbol  is 
the  pair— making  operation.    It  binds  any  particular  X  and  Y 
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together  into  a  pair,  distinguishing  it  as  an  element  o-f  the 
relation.  Note  that  there  must  be  a  space  on  either  side  o-f 
the  operator.  This  is  required  because  this  structure  is 
treated  internally  as  a  LISP  list.  I-f  a  space  is  le-Ft  out, 
an  RPL  error  will  occur. 

To   demonstrate   the  utility  o-f   this   structure,   a 
sequence,  an  array  and  a  record  will  be  de-fined  below: 
sequence  ==  (rel  (1:2)  (2:3)   (3:4)] 

Array    ==  (rel  (1  :  "a")  (2  :  "b")  (3  :  "c")] 
record  ==  (rel  ("#"  :  101)  ("name"  :  "John")  ("age"  :  32): 
Even   more  complex  data  structures  can  be  -formed   easily   by 
combining   these  and  other  primitive  relational   structures. 
For   example,   a  database  is  just  a  set  o-f   records.    Since 
there  are       so  many  di-f-ferent  forms  o-f  a  relation,   RPL   has 
included   syntax   to  simpli-fy  the  de-finition  o-f  two   o-f   the 
more  common  ones,  the  sequence  and  list. 
4-   Seguences 

The   relation  'sequence'  shown  in  section  3  can       be 
entered  as: 

sequence  ==  (seq  1  2  3: 
It  must  be  pointed  out  that  this  is  a  pure  sequence,  i.e.,  a 
relation  which  has  one  initial  element,  one  terminal 
element,  and  is  -fully  connected.  Formally,  it  is  an 
irre-flexive  connected  bijection.  Graphically,  this  sequence 
can  be  represented  as  shown  in  Figure  VI-5. 
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The  label  that  is  put  on  a  node  is  not  important,  so  the 
sequence,   (seq   5  2  10  9) ,   is  equally  as  valid  as  the   one 


• >m >• 

12       3 

Figure  VI-5  -  Graphic  representation  o-f  a  sequence 


shown  in  Figure  VI— 5.   However,  RPL  does  not  prevent  the   user 
from  entering: 

sequence  ==  (seq  5  2  10  9  2  7  7  8) 

This  is  an  invalid  sequence  and  is  represented  graphically: 


::ii^ 


There-fore,  it  is  up  to  the  programmer  to  insure  that  he  is 
de-fining  a  proper  sequence.  The  sequence  operators  do  not 
veri-fy  that  the  structure  passed  to  them  is  a  valid 
sequence.  When  this  occurs,  an  error  can  result,  the 
results  can  be  meaningless,  or  at  worse  the  computation  may 
not  halt  -  -forcing  the  user  to  abort  the  session  and  lose 
everything.  For  this  reason,  caution  is  advised.  On  the 
other  hand,  the  lack  o-f  rigidity  in  sequence  de-finition 
permits  the  easy  representation  o-f  certain  types  o-f  directed 
graphs,  as  the  example  above  points  out. 
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5-   Lists 

The  list  is  just  a  restricted  -form  o-f  an  airraiy  which 
has  a  starting  index  o-f  1 .  An  array,  on  the  other  hand,  can 
have  any  integer  as  a  starting  index.  The  relation  'airraiy' 
shown  in  section  3  is  also  a  list  and  can  there-fore  be 
written  as:  arraiy    ==  (list  "a"  "b"  "c":. 

The  most  common  use  -for  the  list,  and  the  reason  it 
is  included  as  a  separate  entity  in  RPL,  is  to  represent 
argument  lists.  All  mul  ti— parameter  functions  in  RPL  3.re 
represented  internally  in  pre-fix  format  and  use  the  list  as 
their  argument. 
6.   Ranges 

To  simpli-fy  the  data  de-finition  -further  when  dealing 
with  large  numeric  structures,  the  setrange,  seqrange  and 
li strange  syntax  is  provided.  For  example,  it  is  possible 
to  de-fine: 

s  ==  (setrange  1  to  50D 
s'  ==  (seqrange  1  to  503 
1st  ==  (listrange  10  to  601 
These   de-finitions   evaluate   to   the   appropriate   internal 
-forms:    s  would  be  a  set  o-f  the  integers  -from  1  to   50,   s' 
would   be   a   relation  which  relates  each   number   with   its 
successor,   up   to   50,   and  1st  would  be  a   relation   which 
relates  an  index,   starting  from  1,  to  each  value  from  10  to 
60.    The   utility  of  this  syntax  becomes  apparent  when   one 
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thinks   about  what  is  involved  i-F  these  structures  had  to  be 
entered  using  the  general  relation  syntax. 

The  input  -Forms  discussed  in  this  section  can  be  used 
e-f -f  ecti  vely  within  the  RPL  interpreter  to  create  any  ^^orm  of 
data  required.  Sometimes  it  may  be  more  convenient  to  use 
the  simpler  sequence  and  list  syntax  than  the  more  general 
relation  syntax  to  de-Fine  a  desired  data  structure.  For 
example,  suppose  the  user  wanted  a  -Five  element  array  which 
contained  even  numbers  starting  with  2,  and  which  was 
indexed  starting  with  10.  Internally,  the  desired  structure 
would  look  like: 

(rel  (10  2)  (11  4)  (12  6)  (13  8)  (14  10)) 
With  the  relation  syntax  the  user  would  have  to  write: 

a  ==  (rel  (10  :  2)   (11  :  4)   (12  :  6)  (13  :  8)  (14  :  10) D 
He   could  achieve  the  same  result  by  using  the   sequence   to 
3.rra.y    operator,   sa ,   which  takes  a  sequence,  and  a  starting 
index  as  arguments,  and  returns  the  appropriate  array.  Thus, 
he  could  have  typed: 

a  ==  ( (seq  2  4  6  8  10)  sa  10] 
Which   method   is   easier  must  be  decided  by   the   user   and 
depends   upon   his  degree  o-f^    -Familiarity   with   RPL.    Note, 
however,   that   the  second  format  has  less   parentheses   and 
spaces  to  contend  with! 
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F.   FUNCTION  DEFINITIONS 

Although  RPL  contains  a  rich  set  o-f  built-in  operators, 
it  could  never  include  everything,  nor  should  it,  that  a 
user  could  want.  RPL  is  extensible  and  thus  includes  a 
mechanism  -for  de-fining  user  -functions.  As  illustrated  in 
earlier  chapters,  there  Are  three  de-finition  options: 
direct,  pre-fix  and  in-fix.  Most  user  functions  can  be 
de-Fined  using  the  simple  pre-fix  and  in-fix  syntax.  For 
example,  if  the  user  had  a  need  -for  a  -function  which  would 
add  2  to  its  input  and  square  the  result,  he  could  write: 

add2sqr  x  ==  ( (x  +  2)  times  (x  +2): 
For  a  similar,   but  more  general  -function,   which  takes   two 
arguments  he  can  write: 

X  addsqr  y  ==  ( (x  +  y)  times  (x  +  y) 1 
An   alternate   de-finition  -for  addsqr  could  be  written   using 
the  DELTA  operator,   which  duplicates  an  argument,   and   the 
composition  operator: 

X  addsqr  y  ==  ((times  o  DELTA)  (x  +  y) ] 
A   third,   and   even  more  formidable  looking   definition   is 
given  by: 

addsqr  ==  ((times  o  DELTA)  o  (op  +) ) 
The  last  two  definitions  introduce  the  flexibility  of  RPL  by 
showing   how   complex  functional s  can  be  easily   defined   in 
terms  of  built-in  and/or  user  defined  operators. 

There  aLr&  some  cases,  however,  where  the  prefix  and 
infix   definitional   syntax  will  not  meet  the  user's   needs. 
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and  there-fore  the  direct  method  -for  de-fining  -functions  is 
included.  One  utility  o-f  this  syntax  is  its  ability  to 
de-fine  -functions  with  any  number  o-f  parameters.  For 
example,  say  a  -function  called  addsub  is  desired.  This 
-function  adds  its  first  two  arguments  and  subtracts  the 
third.   It  can  be  de-fined  via  the  direct  method  as: 

addsub  ==  (-func  (x  y  z)  (  (x  +  y)  -  z): 
This  is  just  another  way  to  write: 

addsub  (x  y  z)  ==  ( (x  +  y)  -  z) 
Notice  that  the  argument  to  these  functions  must  be  a  RPL 
list  with  three  elements.  The  advantage  of  the  direct 
syntax  over  the  prefix— type  syntax  is  the  ability  of  the 
'func'  definitional  structure  to  be  imbedded  within  another 
function.  This  gives  RPL  the  same  flexibility  as  LISP  with 
its  'LAMBDA'  expression. 

This  same  function  could  be  defined  using  the  prefix 
syntax,  but  the  user  must  be  aware  of  how  RPL  extracts  the 
actual  values  from  the  argument  list  in  order  to  bind  its 
formal  arguments  to  the  actuals.  This  extraction  is  done  by 
use  of  the  RPL  'sel '  operator.  Thus  when  given  a  table  and 
a  member  of  its  domain,  this  operator  will  return  the  first 
member  in  the  range  related  to  it.  Equipped  with  this 
knowledge  and  familiarity  with  the  list  structure,  the  user 
can  also  define  addsub  in  prefix  form  as: 

addsub  x  ==  ( ( (x  sel  1)  +  (x  sel  2))  -  (x  sel  3): 
This  form  and  the  direct  definition  Are    equivalent  and   will 


work   equally  as  well,   but  it  is  obvious  in  this  case   that 
the  direct  method  is  much  simpler  and  more  understandable. 

B.   INPUT /OUTPUT 

1 .   Screen  ingut /Out gut 

All  syntax  presented  thus  -far  is  for  commands  that 
will  be  typed  at  the  terminal  in  an  interactive  session  as 
input.  Output  at  the  screen  is  generated  using  the 
'display'  commands.  To  recall  to  the  screen  any  definition, 
the  user  can  type  the  word  'display'  -Followed  by  the  name  o-f 
the  entity  he  wishes  to  see,  e.g.  , 

display  Array  <CR> 
Notice  that  this  is  the  -First  time  that  the  requirement  for 
a  CArrisigs  return,  -^CR^,  has  been  indicated.  This  is 
because  the  de-Fi ni ti onal  -Forms  discussed  earlier  ended  with 
a  '3'  which  automatically  triggers  execution.  For  commands 
such  as  display,  and  those  that  are  ended  with  a  ') ',  a 
<CR>  is  required.  Execution  o-f  the  command  above  will 
display  the  de-finition  bound  to  the  name  'array'  in  the 
environment.   For  example,  it  might  be: 

array    ==  (list  "a"  "b"  "c") 

The  display  command  can  also  be  used  to  see  the  result 
O-F  a  computation  immediately,  but  once  displayed,  the  result 
is  lost  because  it  will  not  be  bound  to  a  name.  For  example 
i -F  the  user  types  'display  (3  +  5)  '  ,  '8'  will  be  shown. 
Thus  'display'  can  have  any  expression  as  an   argument.    To 
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simpli-Fy  output  to  the  screen,  the  word  'display',  and  two 
shorter  versions,  'dis'  and  'd',  are  optional.  Thus,  only 
the  expression  itsel-F  needs  to  be  typed  to  display  a  result. 

2-   Eile  iOBut /Output 

Any  data  de-finition  can  be  saved  to  a  -file  for 
-future  use  simply  by  typing: 

file  "tablel"  ==  t   <CR> 
This   command   assumes  that  t  has  been   previously   defined, 
e.g.,   as   a  table  of  squares  for  a  finite  range.    To  later 
read  that  table  into  another  RPL  session,  the  user  can  type: 

tbl  ==  file  "tablel"   <CR> 
Since  file  input /output  is  implemented  as  a  special  command, 
it  can  also  be  used  directly  in  an  expression.   For  example, 
the  command   '((file  "tablel")  sel  2)'  would  return  '4'   for 
the  table  of  squares  mentioned  earlier. 

•^-   O^^uggi^ng 

The  final  form  of  output  to  the  screen  in  RPL  was 
implemented  to  assist  debugging.  Since  a  function 
definition  can  involve  the  composition  of  many  operators, 
both  built-in  and  user  defined,  cause— of -error  messages 
might  give  a  strange  response.  This  happens  because  the 
cause  of  the  error  may  be  rooted  in  the  execution  of  one  of 
the  internal  component  functions  within  the  definition. 
Likewise,  there  will  be  times  when  the  user  passes  an 
argument  to  a  function,  but  it  is  rejected  as  the  wrong 
type.    On  these  occasions,   it  is  nice  to  be  able  to   probe 


deeper  into  RPL.  The  'val '  and  'env'  commands  provide  this 
mechanism. 

The  'val '  operator  applied  to  any  name  will  return  the 
evaluated  -form  o-F  the  de-Finition  bound  to  that  name.  Thus, 
i-F  s  is  bound  to  the  sequence  (seq  12  3),  typing  'val  s', 
will  return  '  (rel  (1  2)  (2  3))'.  Similarly,  -for  the 
-function  sum,  defined  as  (;<  +  y)  ,  typing  'val  sum'  would 
return  '(closure  x  (  (>;  sel  1)  +  (x  sel  2)  )  )  ' .  Notice  the 
environment  o-f  de-finition  is  missing.  As  discussed  in 
earlier  chapters,  the  environment  is  omitted  due  to  its 
excessive  length. 

The   'env'   command  provides  the  mechanism  to   view   the 

environments   that  are    omitted  -from  the  display  o-f  functions 

in  evaluated  -form.   The  environment  is  shown  in  de-f i ni ti onal 

form.    Thus,   'env'   alone   will   produce   all   definitions 

created   during  the  current  session.    Applying  'env'   to   a 

function   name   will  produce  all  definitions  visible   within 

its  scope.    For  example,   the  result  of  typing  'env'  for   a 

short  RPL  session  might  be: 

f  ==  (Isec  (times  o  DELTA)  img) 

s  ==  (set  5  6  7  8) 

X  sum  y  ==  (x  +    y) 

arg  ==  (list  2  4) 

System  Defined  Functions 

The  last  definition  put  into  the  environment  is  shown  first. 

'System   Defined   Functions'  constitute  all  of  the   built-in 
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-Function  de-f ini tions  within  RPL.    Finally,   using  the   same 

environment,  typing  'env  sum'  would  return: 

i<    sum  y  ==  (k  +  y) 

arg  ==  (list  2  4) 

System  Defined  Functions 

H.   RELATIONAL  OPERATORS 

In  the  RPL  interpreter  there  ars  112  built— in  relational 
operators  based  upon  the  operations  described  by  MacLennan 
in-  re-ference  2.  All  the  operators  implemented  within  the 
RPL  system  are  discussed  in  detail  in  Appendix  C  and  are 
broken  down  into  classes  based  on  both  the  number  and  type 
o-f  arguments,  and  what  they  return. 

The  operators  are  a  mix  o-f  -first  and  higher  order 
functions..  A  first  order  function  is  one  that  has  data  for 
inputs  and  outputs.  A  higher  order  function  is  one  that  has 
a  first  or  higher  order  function  as  either  input  or  output. 
Since  RPL  has  several  higher  order  functions  they  are 
further  separated  into  two  classes:  those  which  return  a 
function,  and  those  which  have  a  function  as  an  input,  but 
return  data. 

Finally,  there  is  a  group  of  operators  which  a.r&  unique 
because  of  their  special  syntactic  requirements  or  their 
special  handling  required  in  implementation.  They  ar^ 
consolidated  under  the  title  of  'Special  Operators'.  They 
include  the  data  definition  operators,  a  conditional 
functional,   an  iteration  functional,   a  function  to  compute 
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closures,  the  empty  operator,  and  the  'bar'  functional  which 
gives  any  in-fix  operator  a  special  meaning. 

Based  upon  the  preceeding  discussion,  the  operators  are 
broken  into  11  logical  classes  as  shown  in  Figure  VI— 6.  The 
Global  class  o-F  operators  include  those  which  take  anything 
as  an  argument  (s)  ,  or  in  the  case  o-f  'hd'  and  'tl  '  ,  return 
anything.  The  Arithmetic  and  Logical  operators  parallel 
their  conventional  counterparts.  The  next  five  classes  sire 
derived  from  the  type  (form)  of  the  relation  involved. 
Finally,  there  are  the  two  classes  of  higher  order 
operators,  and  the  special  operators. 

1.  Global 

2.  Arithmetic 

3.  Logical 

4.  Set 

5.  Relation 

6.  Sequence 

7.  Array 

8.  Database 

■9.   Higher  Order  —  Return  Function 

10.  Higher  Order  -  Return  Data 

11.  Special 

Figure  VI -6  —  RPL  Operator  Classes 

I.   BEWARE  THE  KEYSTROKE 
1  •  iQtrgduct  i_gn 

Unfortunately,  because  the  RPL  Interpreter  is 
running  within  the  Interlisp  environment  and  the  Unix 
Operating  System,  there  3.r&  a  few  keystrokes  which  may  cause 
unexpected  results.   Some  keystrokes  should  be  avoided,  some 
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should   be   used  with  caution,   and  some  can  be  used  to   the 
user's  advantage. 

2.  Jhe  Control zD  i2Ul   ^nd  Control -C  iClQl 

Pressing  a  ^D  should  be  avoided.  It  will  abort 
whatever  LISP  -function  is  being  executed,  return  the  LISP 
prompt  and  wait  for  the  next  command.  Since  the  RPL 
interpreter  is  invoked  as  a  LISP  command,  a  D  will 
immediately  abort  the  user's  RPL  session,  discarding  all 
work  done  to  this  point.  Likewise,  only  more  severe, 
pressing  a  'C  will  abort  both  RPL  and  Inter  lisp  and  rettcrn 
the  user  to  the  Unix  Operating  System. 

The  "D  and  "C  3.rs  used,  however,  as  part  o-F  the  RPL 
system  to  exit  the  RPL  environment.  They  Are  options  within 
the  RPL  'done'  command  and  should  be  used  only  in  this 
context.  In  general  the  Control  key  should  be  le-ft  alone 
since  there  is  no  meaning  associated  with  control  characters 
in  RPL,  and  they  may  cause  Inter lisp  or  Unix  to  do 
unexpected  and  probably  unwanted  things. 

3.  The  Backspace  Key 

A  second  key  to  be  avoided  is  the  backspace  key. 
For  reasons  not  totally  understood  to  date,  pushing  the 
backspace  key  causes  Interlisp  to  invoke  the  LISP  error 
handling  package.  A  strange  message  appears  on  the  screen, 
which  looks  something  like  'broken  below  0GETTY '  and  a  ':  ' 
prompt  will  appear.  Fortunately,  this  is  not  the  kiss  o-f 
death  as  was  the  -D.   Typing  'RETURN  NIL'  (in  capitals)  will 
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return  the  user  back  to  where  he  was  in  RPL  be-fore  hitting 
the  backspace  key.  I-f  another  strange  message  appears 
followed  by  another  ': '  then  the  user  probably  hit  the 
backspace  key  more  than  once.  A  'RETURN  NIL'  must  be  typed 
■For  each  time  the  backspace  key  was  hit,  and  only  then  will 
Interlisp  return  the  user  to  RPL  in  the  place  it  left  o-ft. 

There  is  one  instance  in  which  this  keystroke 
becomes  an  advantage.  It  can  used  to  temporarily  leave  the 
RPL  environment  to  invoke  any  Interlisp  feature.  Of 
particular  interest  is  the  'BREAKDOWN'  package.  This 
package  allows  the  user  to  do  performance  analysis  of  the 
LISP  functions  used  within  the  RPL  interpreter.  A  more 
detailed  discussion  of  the  benefits  of  this  package  will  be 
presented  in  the  final  chapter.  This  feature  of  RPL  is  of 
real  interest  to  those  individuals  who  3Lre  interested  in 
further  research  with  relational  programming  and  the 
improvement  of  the  RPL  interpreter. 
4.   Jhe  Cgntrgl-Z  ±211 

The  final  keystroke  to  be  discussed  is  the  least 
dangerous,  and  in  fact  has  a  positive  utility.  Hitting  a 
Control— Z  ( '"  Z )  will  temporarily  suspend  whatever  the  user  is 
doing  and  put  him  back  at  the  Unix  logon  level.  The  user 
can  then  execute  any  Unix  command  desired,  e.g. ,  he  could 
look  at  his  directory  to  verify  the  filename  of  a  session  he 
wished  to  load.  When  he  is  finished  at  this  level,  he  types 
'fg'  (lowercase  letters  only)  and  returns  to  the  exact  place 
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he  had  le-ft  o-f-F  when  he  pressed  the  "Z.  Thus  the  programmer 
can  take  advantage  o-f  the  -facilities,  -flexibility  and  power 
o-f  the  Uni;<  Operating  System  concurrently  while  executing  an 
RPL  session. 
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VII.   CONCLUSIONS  AND  RECOMMENDATIONS 

The  primary  goal  o-F  this  prototype  RPL  implementation 
was  to  provide  a  mechanism  for  -future  research.  Prototypes 
generally  have  a  de-finite  starting  point,  which  is  the 
theoretical  work  o-f  its  creator,  the  language  developer. 
What  marks  the  completion  o-f  the  prototype  is  a  design 
decision  that  must  be  made.  Along  these  lines,  one  of  the 
most  difficult  dilemmas  facing  this  implementation  was 
handling  implementation  improvements  that  became  obvious  as 
the  development  progressed.  Without  exercising  restraint, 
implementation  improvements  can  become  an  obstacle  to  timely 
completion.  Unless  specific  performance  criteria  have  been 
set  as  a  system  design  requirement,  and  it  can  be  determined 
that  a  particular  mechanism  of  the  system  must  be  changed  to 
meet  this  objective,  improvements  that  become  obvious  to  the 
prototype  developer  should  be  documented  for  follow  on 
research.  Focus  on  design  issues  can  easily  become  blurred 
and  transition  between  prototype  and  future  r&Bsarch 
obscured  as  improvements  that  become  apparent  to  the 
developer  divert  efforts  from  the  original  goal.  Let  the 
completion  of  the  prototype  be  the  springboard  to 
enhancements  and  efficiency  issues. 

Future  research  on  RPL  was  one  of  the  primary 
considerations   in  this  prototype,   which,   as  discussed   in 
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Chapter  HIi  prompted  its  implementation  in  LISP  using  the 
Interlisp  environment.  Tools  available  in  Interlisp  were  a 
power-ful  incentive  that  in-fluenced  the  choice  decision  ot 
the  implementation  language  used  -for  RPL.  The  cost  of  this 
decision,  however,  was  more  than  anticipated. 

Using  the  Interlisp  programming  environment  can  be  a 
very  -frustrating  experience  to  a  programmer.  Documentation 
available  (CRe-F.  hi  and  CRe-f.  31)  assumes  an  Interlisp  users 
Are  expert  LISP  programmers.  The  system,  called  HELPSYS , 
which  is  usually  a  integral  part  o-f  Interlisp  system 
providing  online  help  messages  to  the  user  is  not 
implemented  -for  UNIX  4.2.  These  obstacles  result  in  a  steep 
learning  curve  to  one  who  desires  to  use  Interlisp  without 
LISP  programming  experience.  Only  hindsight  can  say  that  the 
struggle  and  -frustration  needed  to  become  productive  in  this 
environment  were  well  worth  the  e-f-fort.  The  impact  o-f  seeing 
these  power-ful  tools  in  action  was  an  experience  that 
paralleled  viewing  a  rsire  piece  of  art  that  one  had  only 
previously  read  about. 

It  is  incredible  to  watch  the  speed  with  which  a 
database  is  created  by  MASTERSCOPE  on  the  RPL  system,  which 
consists  of  77  LISP  functions.  The  information  available 
through  queries  to  this  database  provided  the  basic 
documentation  (that  was  only  amplified  slightly)  for  every 
function  shown  in  Appendix  F. 
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This  feature  o-f  Interlisp  will  be  a  de-finite  asset  to 
■future  research.  The  e-f-fects  o-f  changing  a  particular 
mechanism  within  the  RPL  system  can  be  determined  by  making 
a  -few  database  queries.  Figure  VII  — 1  shows  how  the 
in-formation  was  obtained  for  the  documentation  listed  in 
Appendix  F  -for  a  single  -function  and  illustrates  a  -few 
simple  queries.  By  substituting  the  -function  name  with  'all' 
in  the  -first  query,  every  -function  in  the  database  will  be 
'described ' . 

Be-fore  making  speci-fic  changes  to  an  existing 
implementation  o-f  an  operator  or  system  mechanism  some 
concrete  data  may  be  needed  to  veri-fy  perceived  problem 
areas.  This  per-formance  data  is  readily  available  through 
BREAKDOWN.  The  next  section  will  illustrate  this  mechanism 
and  demonstrate  the  use  o-f  the  otherwise  disastrous 
backspace  key  as  an  RPL  interrupt,  allowing  the  programmer 
to  enter  LISP  commands  for  debugging,  editing  and/or 
performance  testing.  Note  that  the  message 
?>  interrupted  below  READP 
(READP  broken) 

will   occur  when  the  backspace  is  pressed  at  the  RPL  prompt. 

The   ': '  prompt  is  the  LISP  break  prompt  and  the   programmer 

has  the  freedom  to  execute  any  LISP  command.  The  command 

:  return  NIL 

will   restore  RPL  to  the  same  position  where  the  session  was 
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interrupted.  Note  that  the  system  will  not  redisplay  the 
line,  ther-Fore  the  cursor  will  be  on  the  first  column  o-f 
what  appears  to  be  a  blank  line. 

The  Array  reduction  operator  was  implemented  in  LISP 
as  part  of  the  kernel.  The  main  consideration  for  the  LISP 
implementation  was  to  make  the  operator  more  efficient.  The 
extensional  definition  suggested  by  MacLennan  CRef .  2  p.  651 
using  a  'while'  functional  was  painfully  slow.  The  current 
implementation  takes  advantage  of  the  fact  that  both 
operands  have  been  evaluated  at  the  time  the  closure  is 
made  (in  BIF_APPLY) -  Therefore,  the  expression  formed  as  the 
body  of  the  closure  has  the  operands  in  evaluated  form.  As 
discussed  in  Chapter  5,  this  operator  could  have  been  easily 
defined  extensional  ly.  In  this  implementation  the  operands 
have  to  be  evaluated  in  ARRAY_REDUCTION.  The  results  of  a 
performance  test  using  BREAKDOWN  is  shown  in  detail  in  the 
following  section.  Of  particular  note  was  the  minor  editing 
of  the  function  ARRAY_REDUCTION  that  was  done  in  order  to 
perform  the  comparison. 

This  type  of  analysis  can  be  done  for  the  composition 
operator  and  parallel  operators.  These  operators  Ars 
currently  implemented  extensional 1 y ,  and  both  operators 
return  closures.  With  the  extensional  implementation  input 
errors  Ar&  not  detected  until  the  function  is  applied. 
Adding  'o'  and  ' I ! '  to  the  kernel  may  enhance  RPL  efficiency 
considerabl y. 
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The  design  o-f  the  RPL  system  allows  the  addition  o-F 
operators  to  the  kernel  without  a  major  coding  e-Ffort.  By 
grouping  operators  in  BIF_APPLY  according  to  the  operand (s) 
requirements,  error  checking  -for  most  operators  is  already 
in  place.  O-F  course  an  in-Fix  operator  being  changed  -From  an 
extensional  implementation  to  the  kernel  will  have  to  have 
its  extensional  de-Finition  removed  -From  INTOPS  and  a 
representative  de-Finition  added  to  SYSYOPS,  as  well  as 
having  its  name  added  to  the  list  BIFTAG_INFIX. 

Much  work  remains  to  be  done  to  determine  which  set  o-F 
operators  is  best  suited  for  the  RPL  kernel.  This  may  be 
answered  through  a  systematic  analysis  o-F  this  prototype 
with  the  tools  provided  by  Interlisp.  More  e-F-Ficient 
implementations  o-F  some  kernel  operators  is  also  likely. 
Additionally,  -Follow  on  implementations  will  have  more 
-Flexibility  with  RPL  notation  i -F  a  character-at— a-time 
parser  is  adopted. 

A.   USING  BREAKDOWN 

In  order  to  illustrate  the  power  and  -Flexibility 
available  to  do  performance  analysis,  edit  functions  and 
create  a  history  of  the  work  performed,  the  following 
example  was  created.  This  example  will  use  the  UNIX  function 
'script'  to  record  the  terminal  session.  In  this  session  the 
factorial  function  will  be  defined  in  terms  of  the  RPL  3.rr3.y 
reduction   operator.    This   function   will   be   used   as   a 
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Script  started  on  Tue  Jun  11  21:94:52  1985 
I   ilisp 
ISI-INTERLISP  15-I1AY-84  ... 

Good  evening. 

_load[rpI-int] 

File  Created:  8-JUN-B5  13:39:37 

RPL-INTCORS 

expanding  LI3TP,  65523  used,  2424832  before  SC 

/work/aiitton/RPL-INT.;2 

_!iiasterscope] 

Hasterscope  28-f1AR-84...  Type  HELP<cr>  for  coisaand  sufSiBary. 

_.  ANALYZE  FUNCTIONS  ON  RECORD 

expanding  LISTP,  131932  used,  2359296  before  GC 
done 

_.  DESCRIBE  EV 
EV[EKP,E] 

calls:  NUMBERP , STR IN6P , ATOM , HEMBER , LOOKUP , ERRORJANDLER , 
EV_SPECIAL.CASES, LENGTH, PREFi:<OP,INFnOp' 

called  by:  EXECUTE, DEFJINDING, DISPLAY, EV_SPECIAL_CASES, 
HAPEV,EVSEQ,INFIKOP,PREFIKOP,RPAPPLy,  " 
ARRAY_REDUCTION,RPL_REPEAT,«AKE_UNIQUE 

binds:    )(,TAG 

uses  free:  SPECIAL_CASES 
NIL 

_.  WHO  CALLS  ERRORJANDLER 

(DISPLAY  EVRANGE  EVSEQ  RPAPPLY  ARRAY_REDUCTION  fllNJET 
RPL.REPEAT  EKECUTE  EV  EV.SPECIAL.CASES  INFIXOP  PREFIXCP 
BIF.APPLY  ARRAY_CQNCATENATIQN  HEAD  MAK.SET  nEM 
_.  WHO  USES  ERRORCODE 

(RPL  ERRORJANDLER  FILTER  READ_USER_DEFS  DEFJINDING 
DISPLAY  EV_SPECIAL_CASES  EVSEQ  INFHOP  PREFIXQP  RPAPPLY 
•  BIF.APPLY  RPL_REPEAT) 
_.  m   SETS  ERRORCODE 
(RPL  ERROR  HANDLER  FILTER  READ  USER  DEFS) 
_.QK 
NIL 
I  'l 

script  done  on  Tue  Jun  11  21:23:02  19S5 
I 


Figure  VII-1  ~  Example  of  LISP's  flasterscope  Feature 
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benchmark  to  examine  the  'red'  operator  implementation.  The 
current  implementation  o-f  'red'  is  done  in  LISP  using  the 
techniques  described  in  Chapter  5,  and  will  be  compared  to 
two  extensional  implementation. 

Ampli-fying  remarks  for  notes  in  Figure  'v'II-2: 

1.  The  file  'brkdwn. sess '  initialized  by  the  UNIX 
'script'  function  to  record  the  terminal  session. 

2.  RPL  system  functions  are  loaded  into  Interlisp. 

3.  The  command  'BREAKDOWN'  followed  by  a  list  of 
functions  will  internally  mark  these  functions  for 
monitoring   in   the  performance   analysis   during   the 

iion. 


4.  Factorial  function  defined  as  a  benchmark. 

5.  'Backspace'  (BS)  key  causes  an  interrupt  to  the  RPL 
session. 

6.  The  command  'breakdownC U '  will  zero  internal  counters 
for  the  performance  analysis.  This  is  done  so  that 
any  data  accumulated  during  RPL  loading  and  the 
definition  of  'fac'  will  not  distort  analysis. 

7.  The  command  ' brkdwnresul tsC D '  is  used  to  verify  that 
the  counters  Are    zeroed. 

S.  The  command  'return  NIL'  is  used  return  to  RPL. 

9.  The  RPL  command  ' (fac  5) '  is  entered  for  benchmarking. 

10.  BS  interrupt  (See  #5). 

11.  The  data  generated  from  BREAKDOWN  is  retrieved. 

12.  The  LISP  editor  is  used  to  modify  ARRAY_REDUCTION. 
This  is  necessary  since  f  and  i  Are  passed  in 
evaluated  form  in  the  current  implementation. 

13.  Return  to  RPL  (See  #8). 

14.  An  extensional  version  of  the  a.rra.y  reduction  operator 
is  defined,  and  a  factorial  function  using  this 
operator  is  defined. 
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15.  BS  interrupt  (See  #5). 

16.  Counters  a.re    zeroed  using  '  breakdownC  D  '  command. 

17.  Return  to  RPL  and  benchmark  program  ran  ('-facext"). 

18.  BS  interrupt  (See  #5). 

19.  Performance  data  is  obtained. 

20.  Return  to  RPL  (See  #8). 

21.  Array  reduction  is  de-fined  by  translating  the 
definition  used  by  Maclennan  CRe-f.  21.  This 
illustrates  the  shift  in  the  use  of  sequences  to  lists 
as  functional  arguments.  The  poor  preformance  shown 
below  led  to  the  implementation  used  in  the  first 
ex  amp 1  e . 

22.  BS  interrupt  (See  #5). 

23.  Counters  in  BREAKDOWN  zeroed. 

24.  Return  to  RPL  and  benchmark  program  ran  (FAC) . 

25.  BS  interrupt  (See  #5). 

26.  Performance  data  is  obtained. 

27.  '  ■-C '  terminates  the  Inter  lisp  process  and  returns  the 
process  to  UNIX. 

28.  '"D'  terminates  the  session  and  v-i^rites  '  brdwn .  ssss  '  . 
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I   script  brkdwn.sess 

Script  started  on  Sat  Jun  8  12:46:09  1985 

I   ilisp 

ISI-INTERLISF  15-l1AY-e4  ... 

Hi. 

loadErpl-int] 

File  Created:  6-JUN-35  04:04:45 

RPL-INTCOilS 

expanding  LISTP,  65520  used,  2424832  betore  GC 

/Mork/siitton/RPL-INT 

.breakdown  (EV  EV_SPECIAL_CA3ES  RPAPPLY  INPHOP  PREFHOP  BIFJPPLY] 

(EV  EV_SPECIAL_CASE3  RPAPPLY  INFIKOP  PREFIXOP  BIF.APPLY) 

_[RPL]' 

Loading  RPL—  DO  YOU  i^ANT  TO  RESUME  A  PREVIOUS  RPL  SESSION?  <y/n>  N 


NOTE 
1 


RPL  INTERPRETER  ON  LINE!' 

?>  lac  n  ==  (((up  tiiTies)  red  I)  (listrange  1  to  n] 

''>  interrupted  below  READP 

(READP  broken) 

:breakdDwn[] 

(EV  EV.SPECIAL.CASES  RPAPPLY  IWIW  PREFi:/OP  BIF.APPLY) 

:brkdwnresults[] 


FUNCTIONS    TIHE 
EV        0.0 
EV.SPECIAL.CASES 
3.3 
RPAPPLY     3.3 
INFIXQP     3.3 

?mnm       0.e 

BIF.APPLY  0.0 
TOTAL  0.3 
NIL 

:return  NIL 
READP  =  NIL 
(fac  5] 

120 


*  CALLS   PER  CALL 
0     0.0 


I 


Figure  VII-2  --  RPL  Terainal  Session  Using  BREAKDOWN 
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?>  interrupted  below  READP 


le 


(READP  broken) 
:brkdwnre5ult5[] 


11 


FUNCTIONS  TIME 
EV  1.12 
EV.SPECIAL_CASE3 

0.224 
RPAPPLY  3.24 
INFIXOP  0.592 
PREFHOP  9.343 
BIF.APPLY  I. .056 
TOTAL  3.28 
NIL 

:editf(ARRAY_REDUCTION] 
edit 
♦F  FNC 
»F  FNC 
*0  P 

(SETQ  FNC  (CADDDR  EXP)) 
*.3  P 

(CADDDR  UP) 
»(-l  EV) 
»(N  EA] 
»P 

(EV  CADDDR  UP   EA) 
*BI  2  3 
*P 

(EV  (CADDDR  EXP)  EA) 
#F  START 
*P 

...  START  (CADDDR  Vi) 
♦0  P 

(SETQ  START  (CADDDR  t)) 
*3  P 

(CADDDR  (CDDR  EXP)) 
*(-!  EV) 
»(N  EA] 
*P 

(EV  CADDDR  (CDDR  EXP)  EA) 
»BI  2  3 
*P 

(EV  (CADDDR  5()  EA) 
*0K 

ARRAY_REDUCTION 
;return  NIL 
READP  =  NIL 


I  CALLS   PER  CALL 


64 


16 
2 

16 
124 


17=; 


V 

34 


3746667  7 

010434a  7 

037  13 

824  1 

066  32 
0264516 


12 


Figure  yiI-2  —  RPL  Tersiinal  Session  Using  BREAKDOWN  (continued) 
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i   redext  i  ==  (func  ^A  (reduce  ''A  by  f  froa  il  14 

?>  facext  n  ==  (!(op  tiaes)  redext  1)  (listrange  I  to  n] 

''>  interrupted  below  READP  15 

(READP  broken) 

:br83kdown[]  16 

(EV  EVJSPECIAL.CASES  RPAPPLY  INPHOP  PREFIXOP  BIF_APPLY) 

.■return  NIL  17 

READP  =  NIL 

(•facext  5] 

128 

''>  interrupted  below  READP  IB 


19 

=ER  CALL  7. 

3.3176714  35 

0.356  7 

0.3153043  11 

0.035  17 

3.832  2 

0.064  29 
3.9263307 


21 

?>  s2  ==  (rsec  sel  2] 
?>  p  ==  ((rsec  <)  etpty)  o  52] 
?>  cdr  ==  ((I  (\  bar)  (un  o  epsilon))  o  sU 
''>  arg  ==  (I  II  (tl  o  epsilonl 

^>  -f  RED  i  ==  (si  0  (((((-f  0  arg)  H  cdr)  o  DELTA)  while  p)  o  (Isec  i  ,3 
r>  FAC  n  ==  ({(op  tiaes)  RED  1)  (listrange  1  to  n] 
?>  interrupted  below  READP  22 

Figure  VII-2  --  RPL  TeriBinal  Session  Using  BREAKDOWN  (continued) 


(READP  broken 

) 

:brkdwnresult 

5[] 

FUNCTIONS 

TIME 

1  CALL 

EV 

1.184 

67 

EV_SPECIAL_CA3ES 

0.224 

4 

RPAPPLY 

0.352 

23 

INFIKQP 

0.56 

16 

PREFIXOP 

3.064 

2 

BIF  APPLY 

0.96 

15 

TOTAL 

3.344 

127 

NIL 

:return  NIL 

READP  =  NIL 

si  ==  (rsec  5 

el  1] 
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(READP  broken) 

:breakdown[] 

(EV  EV_SPECIAL_CASES  RPAPPLY  INPHOP  PREFIKOP  BIF_APPLY) 

:rsturn  NIL 

READP  =  NIL 

(FAC  5] 


23 


24 
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?>  interrupted  below  READP 


(READP  broken 

) 

:BRKD«NRE3LILTS[] 

FUNCTIONS 

TIMETIME 

1  CALLS 

PER  CALL 

V 

EV 

9.392 

497 

0.0188974 

40 

EV.3PECIAL_CA3ES 

1.808 

-J -J 

0.0547379 

8 

RPAPPLY 

3.2 

161 

3.0193758 

14 

INF  nop 

2.964 

51 

0.0404796 

9 

PREFHOP 

2.88 

100  • 

kJ.9288 

12 

BIF_APPLY 

3.872 

58 

0.0667586 

17 

TOTAL 

23.21i 

909 

0.0257956 

NIL 

"C 

I  'D 

script  done  on  Sat  Jun 

8  13:33:33 

1985 

26 


27 
28 


Figure  VI 1-2  —  RPL  Teriinai  Session  Using  BREAKDOWN  (continued! 
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APPENDIX  A  -  ORIGINAL  RPL  GRAMMAR 


session    -     command    done 

(prefixid  \identifier\   =    expr 
display  expression 


expression    — 


application 


[expression  infix]   application 
superscription 

[application]  primary  | 

iter  [  primary  ->   primary  ]  I 


application 


superscription    =     expression  sup" 


/ 


primary 


lite  ral 

prefixid 

( 
infix 

infix  primary 

primary  infix 

primary  —>   primary  ;  primary 

(   expression  |  ..  expression]   ) 
{  expression  [..  expression]   } 
<    primary  ,     ■  •  ■    > 
file  string 


J 


infix    =     infixop  ,  bar 
identifier   =    letter 


letter 
digit 


prime 


prime 


lite  ral 


(  \ 

digit  ^  I  .  digit '^\ 

string 

true 

false 


/ 


string     -     "   char 
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infix  op    — 
sel  I  ,  :  cup  member  nomem  !subset  subset  =   ->    <  -  restr  ;  cl  cr  cap  \ 
@  hat  !  cat  @    .\\  $  red  +    -  times  divide  !=<><=>  = 
ajidsign  orsigii  cart 


(identifier 
prejixop 


prefixop    = 
-  un  cur  unc  theta  size  str  DELTA  inv  dom  rng  mem  Lm  Rm  Mm  run  lun  bun 
init  term  alpha  omega  ALPHA  OMEGA  min  max  mu  index  select  join  as  sa  saO 
rp  rpi  rsort  sort  unimg  all  ssm  img  curry  uncurry  PHI  Id  while  upsilon 
phi  delta  PI  extend  restrict  wig  not 
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APPENDIX  B  -  IMPLEMENTED  RPL  GRAMMAR 


session 
command 


expression 
appl i  cation 
superscript! on 
primary 


in-f  i  .< 

formal s 

identifier 

prime 

literal 


str i  ng 
pref  i  xi  d 

i  n  f  i  K  i  d 


=  (command)*  (done) 

=  prefix  id  [identifier]  ==  expression 

=  identifier  infixid  identifier  ==  expression 

=  file  string  ==  expression 

=  Cdisplay  I  dis  !  dI3  expression 

=  val  identifier 

=  env  C identifier] 

=  (expression  infix  expression) 

=  application 

=  superscription 

=  primary 

=  (application  primary) 

=  (iter  primary  — >  primary) 


(expression  sup 
(expression  sup 
(expression  sup 


appl i  cati  on) 
**) 


1 i  teral 

pref ixid 

(op  infix) 

(rsec  infix  primary) 

(Isec  primary  infix) 

(if  primary  — >  primary  ;  primary) 

(rel  (expression  :  expression)   ... 

(seqrange  expression  to  expression) 

(setrange  expression  to  expression) 

(li strange  expression  to  expression) 

(seq  primary 

(set  primary 

(list  primary 

(file  string) 

(func  formals 

empty 


) 
) 
) 

expressi  on) 


infixid 
(inf  ix  i  d 


bar) 


=  identifier 

=  (identi f i er+) 

=  letter  [letter  !  digit]*  prime* 


=  digit+ 
=  string 
=  true 
=  false 

=  "char*" 


i  denti  f  i  er 
pref ixop 

i  denti  f  ier 
inf  i  xop 


C.  digit+] 
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pre-fiKop         =  un 

=  cur 


=  unc 

=  theta  Primitive  Extensionals 

=  epsilon 

=  size 

********************************************* 

=  DELTA 

=  cnv 

=  rev 

=  dom 

=  rng 

=  mem  h4on— Primitive  Extensionals 

=  run  (Group  I) 

=  1  un 

=  bun 

=  ini  t 

=  term 

=  hd 

=  tl 

=  alpha 

=  omega 

=  ALPHA 

=  OMEGA 

=  min  Non— Primitive  Extensionals 

=  max  (Group  II) 

=  uset 

=  mu 

=  as 

=  rsort 

=  sort 

=  ssm 

********************************************* 

=  curry 

=  uncurry        Primitive  Intensionals 

=  I 

=  whi le 

=  upsilon 

=  phi  Non_Pr i mi ti ve  Intensionals 

=  delta 

=  PI 

=  wi  g 

******************************************** 
=  not  Miscellaneous 
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in-fixop  =  sel 


I 

—  I 

=  ,  Primitive  Extensionals 

=  cup 

=  member 

=  nomem 

=  Lm 

=  Rm 

=  Mm 

=  ! subset 

=  subset         Non— Primitive  Extensionals 

=  =  (Group  I) 

=  filter 


=  restr 

~  5   . 

=  index 

=  select 

=  join 

=  un  i  mq 

=  all 

=  cl 

=  cr 

=  cap  Non— Primi ti ve  Extensionals 

=  \  (Group  II) 

=  rp 

=  rp. 

=  ©hat 
=  X  i 

=  sa 
=  cat 


Primitive  Intensionals 


=  @ 

=  o 

I  I 

—  I  ■ 

=  * 

=  img 

=  PHI 


=  red 

=  extend         Non— Primi tive  Intensionals 

=  restrict 


t  i  mes 
divide  1  / 

•  =   '   ■:;"  ■> 

Mi  seel  1 aneous 


andsign  I  and 
orsign  !  or 
cart 
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APPENOIX  Q    Z  BEL  QPERATORS 

A.   INTRODUCTION 

This  appendix  will  describe  all  the  RPL  operators 
implemented  to  date.  Sections  B  -  L  each  cover  one  of  the 
operator  classes  outlined  in  Chapter  VI.  Because  all  o-f  the 
data  input  operators  are  included  in  the  'Special  Operator' 
class,  it  is  discussed  -first,  -followed  by  the  the  remaining 
classes  in  the  order  indicated  in  Chapter  VI.  Also,  to 
provide  easier  access  to  the  operators,  an  index  is  included 
at  Appendix  D. 

The  -format  utilized  provides  the  user  with  the  name  of 
the  operator  in  -functional  terms,  its  syntax, 
input  (s) /output ,  a  description  o-f  what  the  operator  does, 
and  one  or  more  examples.  Each  example  is  written  as  an  RPL 
command  which  will  return  a  result.  There-fore,  de-finition 
o-f  variables  is  kept  to  a  minimum  to  keep  the  structures 
visible  so  the  user  can  -follow  more  easily  what  is 
happening. 

Long  input  de-finitions  and  output  Are  highly  formatted 
in  this  appendix.  The  user  must  realize  that  output  from 
the  interpreter  itself  is  not  as  structured.  A  large 
relation  in  RPL  is  just  a  LISP  list,  and  so  when  it  is 
printed  to  the  screen,  it  is  printed  as  a  single  long  list, 
modified   slightly  by  RPL  routines.    Therefore,   the  output 
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represented  in  this  Appendix  has  been  nicely  -formatted  to 
clarify  the  structures  involved  and  to  help  the 
understanding  o-f  the  user. 

Arguments  to  RPL  operators  can  take  various  -forms,  but 
Are  all  variations  o-f  the  three  basic  types  —  scalars,  sets 
or  relations.  In  general,  data  types  will  be  represented 
through  the  use  o-f  lowercase  letters  as  -follows: 

X,  y,  z        ==>        scalar,  or  anything 

s  ==>        set 

t,  u  ==>        relation  (table) , 

sequence  or  list 

d  ==>  relation  —  database 

-f ,  g           ==>  -function 

p  ==>  boolean  function 

m,  n            ==>  integers 

The  operators  have  generally  been  classified  by  the  type 
of  argument  they  apply  to,  e.g.,  set,  relation,  sequence, 
3Lrra.y.  Sequences,   arrays,   records   and  the  like  Sirs       all 

special  forms  of  a  relation.  Another  unique  form  of 
relation  utilized  by  several  of  the  higher  order  operators 
is  the  data  structure. 

A  RPL  data  structure  consists  of  two  parts,  the  form 
part,  R,  and  the  data  part,  D.  These  two  parts  Are  combined 
as  a  RPL  list.   Thus,  the  internal  structure  appears  as: 

(rel  (ID)   (2  R) ) 
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R,   the   -form   component,   is  a  relation   represented   as   a 

sequence  o-f  indices  to  the  data  elements.   These  indices  can 

be   anything   the   user  desires,   as  long  as   they   all  arB 

distinct.    The   data   part,   D,   is  also  a   relation   which 

relates   the  indices  to  their  respective  data   values.    For 

example,   consider   a  data  structure  -for  the  sequence, 

(10,  20,  30,  40,  50). 

For  simplicity,  let  the  -form  part,  R,  be  represented   by  the 

sequence,   (1,  2,  3,  4).   Internally,  R  would  look  like: 

(rel  (12)  (2  3)  (3  4)  ) 

This  would  lead  to  the  data  part,   D,  with  an  internal  -form: 

(rel   (1  10)  (2  20)  (3  30)  (4  40)) 

Together  these  components  would  produce  the  data  structure: 

S  =  (rel  (1  (rel  (1  10)  (2  20)  (3  30)  (4  40))) 
(2  (rel  (12)  (2  3)  (3  4)))  ) 

In   this  appendix,   a  data  structure  will  be  represented   b'/ 

the  capital  letter,  'S'.   This  letter  is  used  to  distinguish 

it   -from   the  lowercase  letters  which  3.re    used  to   represent 

other  argument /data  typ^^  in  the  language. 

For  additional  and  developmental  in-formation   concerning 

any   of   the   operators   in   this   Appendix,   see   MacLennan 

CRe-f.  21.    Some   operators   have   been   altered,   added   or 

deleted   -from   the   original   set   proposed   by    MacLennan. 

Appendix   E  summarizes  in  tabular  -form,   the  evolution   from 

the    original   proposal   to   the   implemented   version    o-f 

operators.    It   provides  a  quick  re-ference  to  the  syntax  of 
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the  operators  in  their  input  -form  and  contrasts  this  input 
•form  with  the  publication  -form  created  through  the  use  o-f 
the  Unix  'eqn'  package. 

B.   SPECIAL  OPERATORS 

1 .  Rel^at i_on  De£i_ni_t i_gn 

a.  Syntax:         (rel  (xl  :  yl)  <x2  :  y2)  ...  ) 

b.  Input (s) :      anything 
Output:        relation 

c.  Description:   The   'rel'  operator  is  the  general 

mechanism  to  create  a  relation  in 
RPL.  It  normally  uses  the  pair- 
making  operation  described  in  the 
next  section  to  convert  the  data 
given  into  the  internal 
representation  -for  a  relation. 

d .  Ex  amp 1 e ( s ) : 

7>  (rel  (1:2)  (3:4)  (4  :  5)  3 
(rel  (12)  (3  4)  (4  5)) 

2.  Set  Definition 

a.  Syntax:         (set  xl  x2  x3  ...  ) 

b.  Input  (s):      anything 
Output:        relation  (set) 

c.  Description:   The   'set'  operator  evaluates   and 

trans-forms  the  data  items  given 
into  the  internal  representation 
-for  an  RPL  set. 

d.  Example(s):    Suppose  a  =  3  and  b  =  5: 

?>  (set  1  2  a  4  b: 
(set  12  3  4  5) 

•3-   Seguence  Definition 

a.   Syntax:         (seq  xl  x2  x3  ...  ) 
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b.  Input (s) :      anything 
Output:         relation 

c.  Description:   The   'seq'   operator  is  an   easier 

way  to  enter  a  special  kind  o-f 
relation  called  a  sequence.  It  is 
up  to  the  user  to  insure  that  the 
data  item  he  is  creating  is  a  pure 
sequence,  i.e.,  has  no  redundant 
elements  in  it.  This  mechanism 
can  also  be  used  to  enter  certain 
types  D-f  directed  graphs  when 
redundant  elements  Are    included. 

d.  Example (s) : 

(1)  ?>  (seq  1  2  3  4  5D 

(rel  (12)  (2  3)  (3  4)  (4  5)  ) 

(2)  ?>  (seq  S  3  7  7  5  4: 

(rel  (8  3)  (3  7)  (7  7)  (7  5)  (5  4)) 

4.   Li_st  De£i_niti^gn 

a.  Syntax:         (list  xl  x2  x3  ...  ) 

b.  Input (s):      anything 
Output:        relation 

c.  Description:   The   'list'  operator  is  an   easier 

method  to  enter  a  relation  which 
looks   like  an  Array.  It  sets  up 

an  internal  structure  which  orders 
the  data  given  by  relating  an 
index,  starting  with  1,  to  the 
value  provided.  It  is  called  a 
list  a-Fter  its  primary  use,  tor 
making  argument  lists  -for  in-fix 
•functions. 

d.  Example(s):    Suppose  x  =  30: 


'-i  --. 


(list  10  20  X  40: 
(rel  (1  10)  (2  20)  (3  30)  (4  40)) 

5.  Rgnge  De£i_ni_tign  -  Setj_  Seguencej_  and  Li^st^ 

a.   Syntax:         (setrange  m  to  n) 

(seqrange  m  to  n) 
(listrange  m  to  n) 
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b.  Input (s):      integers 
Output:        relation 

c.  Description:   These  operators  are    used  to  easily 

create  relatively  large  numeric 
relations.  The  values  within  the 
range  -from  m  to  n  Bre  trans -Formed 
into  the  appropiate  structure. 

d.  Example (s) : 

(1)  ?>  (setrange  2  to  5^ 

(set  2  3  4  5) 

(2)  ?>  (seqrange  1  to  53 

(rel  (12)   (2  3)  (3  4)  (4  5)  ) 

(3)  ?>  (listrange  10  to  303 

(rel  (1  10)  (2  20)  (3  30) ) 

Direct  Function  Definition 

a.  Syntax:        name  ==  (func  (arg)  (body)) 

b.  Input  (s):      argument  list;  body  of  de-Finition 
Output:         RPL  function 

c.  Description:   The   syntax   includes   the   entire 

command  line  required  to  execute  a 
'func'.  The  function  components 
provided  Are  converted  into  the 
RPL  internal  function  representa- 
tion and  the  environment  of  defin- 
ition is  attached.  However,  this 
environment  is  never  displayed  to 
the  screen  in  evaluated  form.  The 
'env'  command  will  allow  the  user 
to  see  the  environment  of  any 
function  in  its  definitional  form. 
The  'val'  command  will  allow  the 
user  to  see  the  internal  repre- 
sentation of  a  function,  but  the 
environment  will  not  be  displayed. 

d  .   Ex  amp 1 e ( s ) : 

?>  sum  ==  (func  (x  y)  (x  +  y)  H 
?>  val  sum 

( c 1 osur  e  ( x  y )  ( x  +  y ) ) 
?>  (sum  (list  2  3) : 
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7.   ln£i.K  to  Prefix  Conversion 

a.  Syntax:         (op  -F ) 

b.  Input  (s)  :      in-fix  function 
Output:        pre-fix  -Function 

c.  Description:   The   'op'  operator   trans-forms   an 

in-Fix  operator  into  a  prefix 
operator  so  that  it  can  be 
composed  with  other  -functions. 
Once  converted  the  arguments  to 
this  function  must  be  provided  in 
the  form  of  a  binary  list. 

d .  Ex  amp  1  e  ( s )  : 

?>  (  (op  +)  (list  2  311 
5 

S.   Left  Sectj^gn  and  Right  Secti_gn 

a.  Syntax:         (Isec  x  f) 

(rsec  f  x) 

b.  Input (s):      x,  anything;  f,  infix  operator 
Output:        function 

c.  Description:   These  two  operators  allow  the  user 

to  fix  either  the  left  or  right 
argument  to  an  infix  function. 
Thus  X  must  be  a  suitable  argument 
to  the  infix  function  provided. 

d.  Ex amp 1  e  (s)  : 

(1)  ?>  (  (Isec  3  +)  2D 

5 

(2)  ?>  ( (rsec  =  3)  2: 

f  al  se 

9.   Cgndj^tignal^  EyDcti_gnal^ 

a.  Syntax:         (if  p  — >  f  ;  g) 

b.  Input (s):      p,  predicate  —  boolean  function 

f ,  g  -  any  function 
Output:         function 
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Description:  This  functional  creates  a  -function 
which  when  given  an  argument  will 
pass  it  to  the  predicate.  I-f 
true,  then  f  will  be  applied  to 
the  argument,  else  g  will  be 
applied  to  the  argument. 

Example(s):  Suppose  the  user  wanted  to  add  or 
subtract  two  numbers  based  on  the 
sign  o-f  the  first  number.  The 
following  predicate  and  functions 
could  be  used  (See  Chapter  VI  for 
explai nation  of  function  defini- 
tional forms: 

?>  p  >i    ==  (  (k  sel  1)  <  0: 

?>  f  ==  (op  -»-: 

?>  g  ==  (op  -3 

?>  ((if  p  ->  f  ;  g)  (list  3  23 


10.   Iterati^gn  Functional, 

a.  Syntax:         (iter  p  ;  f) 

b.  Input (s):      p,  predicate  (boolean  function) 

f ,  any  function 
Output:         anything 

c.  Description:   This     functional    produces     a 

function  which  when  given  an 
argument  will  apply  f  to  that 
argument  at  least  once.  Then  if 
the  predicate  applied  to  the 
result  of  the  first  application  of 
f  is  true,  it  will  apply  f  to  the 
result.  This  cycle  continues 
until  the  predicate  fails. 

d.  E;<ample(s):    Consider   a  trivial  case  where  the 

user  wanted  the  argument  to  be 
doubled  until  it  was  greater  than 
50,  and  then  return  the  result: 

?>  p  ==  (rsec  O  50] 
?>  f  =  (rsec  times  2  3 
?>  (  (iter  p  ->  f )  4: 
64 
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1 1 .   SugerscrlEt ign 
a.   Syntax: 


b.   Input (s) : 

Output: 
c-   Description; 


(t  sup  +)  ' 

(t  sup  **) 

(t  sup  -1) 

(-f  sup  n) 

t,  relation 

f ,  -Function;  n,  positive  integer 

relation;  function 

This  operator  has  four  cases  as 
shown  above  and  is  the  only  one 
that  can  be  applied  to  both  ei< ten- 
si  onal  relations  and  functions. 
When  the  right  argument  is  '+'  a 
transitive  closure  is  performed. 
When  a  ' ** '  is  provided,  a  reflex- 
ive transitive  closure  is  done. 
Note,  a  double  asterisk  is 
required  because  of  a  conflict 
with  the  use  of  the  '*'  symbol  in 
LISP.  When  a  '-1'  is  the  right 
argument,  the  converse  of  t  is 
returned.  When  the  left  argument 
is  a  function  and  the  right 
argument  is  a  positive  integer, 
the  function  is  composed  with 
itself  n  times. 


d.   E;(ample(s):    Let  t  =  (seq  1  2 

f  =  (x  +2) 


4> 
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(1)  ?>  (t  sup  +1 

(rel  (1  2)  (2  3)  (3  4)   (1  3)  (2  4)  (1  4)) 

(2)  ?>  (t  sup  **: 

(rel  (1  1)   (2  2)  (3  3)  (4  4)   (1  2) 
(2  3)  (3  4)  (1  3)  (2  4)   (1  4)  ) 

(3)  ?>  (t  sup  -1] 

(rel  (2  1)  (3  2)  (4  3)  ) 

(4)  ?>  ( (f  sup  2)  23 

8 

Formalization  Functional 


Syntax : 


(f  (+  bar)  g)  , 
(f  (-  bar)  g)  , 
(f  (times  bar  g)  , 
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functions 

-F  and 

argument 

and 

'barred ' 

infix 

resul ts. 

Consider 

a  def 

b.  Input (s):      infix  operator;  functions 
Output:        function 

c.  Description:   The   'bar'   operator  converts   any 

infix  operator  into  a  functional 
which  takes  two  functions  as 
arguments.  The  resulting  func- 
tional   will    apply   the    input 

g  to  an  appropiate 

then    apply    the 

operator   to   the 

d.  ExampleCs):    Consider   a  definition  for  a  func- 

tion which  squares  its  arguments. 
It  utilizes  the  Identity  function, 
I,  which  is  explained  in  the  next 
section: 

?>  sqr  ==  (I  (times  bar)  11 
?>  (sqr  4: 
16 

3.       EnJEty    Set    or    Rel_ati_gn 

a.  Syntax:        empty 

b.  Input (s):      none 

Output:         set  or  relation 

c.  Description:   This   operator  is  actually  a   data 

element  which  represents  the  empty 
set  or  relation.  It  is  normal  ly^ 
used  to  initialize  sets  or 
relations  and  may  be  returned  as 
the  result  of  other  operations. 

d.  Example (s) : 
?>  X  ==  empty 

GLOBAL  OPERATORS 

1-   Egual_i^tY  and  Xnegual^i^ty 

a.  Syntax:         (x  =  y) 

( X  !  =  y )   or   ( x  <  >  y ) 

b.  Input (s):      anything 
Output:         boolean 
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c.   Description:   Compares   any   two  RPL  data   types 

based  upon  their  mathematical 
equivalence,  not  form. 

d-   Example (s) : 

(1)       ?>    (2   =   Zl  (2)       7>    (2    !=    3: 

-False  true 

(3)       ?>     ((set     (1:2)     (2:3)     (3:4))=     (seq    1234] 
true 

2.  OyBiicstign 

a.  Syntax:         (DELTA  x) 

b.  Input (s):      anything 
Output:        relation 

c.  Description:   Duplicates    the    argument     and 

returns  a  relation  in  the  form  ot 
a  binary  list. 

d.  Example (s):    ?>  (DELTA  "a"] 

(rel  (1  "a")  (2  "a") ) 

3.  Identity 

a.  Syntax:         (I  x) 

b.  Input (s) :      anything 
Output:         anything 

c.  Description:   Returns  the  input  unchanged. 

d.  Example(s):    ?>  (I  33 

4.  P^iC  E9!lQ]^tlQQ 

a.  Syntax:         (x  :  y) 

b.  Input (s):      anything 
Output:        elementary  pair 

c.  Description:   Used   to   create  the  elements  o-f  a 

relation  in  conjunction  with  other 
operators.  It  has  no  meaning  by 
itsel-f  . 

d.  Example(s):     (1:2)   ==>   (1  2) 
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5-   Headi  Tai.1. 

a.  Syntax:         (hd  z) 

(tl  z) 

b.  Input (s):      elementary  pair 
Output:        anything 

c.  Description:   Given   a   LISP   elementary    pair, 

i.e.,  a  dotted  pair,  'hd'  will 
return  the  -first  element,  'tl' 
will  return  the  last  element. 
These  operations  Ars  used  within 
-function  de-finitions  to  extract 
pieces  o-f  a  relation  which  can  be 
-further  processed. 

d.  Example (s) : 

(1)  7>  (hd  (10  :  2(33 

10 

(2)  ?>  (tl  (10  :  (rel  (3  :  4)  (4  :  53 

(rel  (3  4)  (4  5)  ) 

6.  E^ic  List 

a.  Syntax:         (x  ,  y) 

b.  Input (s) :      anything 
Output:        relation 

c.  Description:   Converts   the  two   inputs  into  the 

relational  -form  o-f  a  binary  list. 

d.  Example(s):    ?>  (20  ,  303 

(rel  (1  20)  (2  30) ) 

7.  Unit  Set 

a.  Syntax:         (un  x) 

b.  Input (s) :      anything 
Output:         set 

c.  Description:   Converts   the  input  data  item  to  a 

set  containing  that  single  data 
i  tern. 

d.  Example(s):    ?>  (un  "dog": 

(set  dog) 
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D.   ARITHMETIC  OPERATORS 

1 .   Sumj.  Difference  J.  Prgduc  t  j.  Qugt  i_en  t 

a.  Syntax:         (;<  +  y) 

(X  -  y) 

(x  times  y) 

(x  divide  y)   or   (x  /  y) 

b.  Input (s):      numeric,  real  or  integer 
Output:        numeric,  real  or  integer 

c.  Description:   Normal   mathematical    operations. 

I-f  either  input  is  a  real,  the 
result  will  be  a  real,  except  in 
division.  I-f  the  numerator  is 
integer,  an  integer  division  will 
be  executed. 

d.  Example (s) : 

(1)   ?>  (2  +  3:  (2)   ?>  (3.125  -  23 


vj 


1.  12! 


(3)   ?>  (3  -  2:  (4)   ?>  (2  *  4: 

1  8 

(5)   ?>  (2  divide  4:     (6)   7>  (2.0  /  43 
0  0.5 

2.   L=es5j^  Greater  J.  Less  or    Egual_j_  Greater  or    Eguai^ 

a.  Syntax:         (x  <  y) 

(X  >  y) 
(X  <=  y) 
(x  >=  y) 

b.  Input (s):      numeric,  real  or  integer 
Output:         boolean 

c.  Description:   Conventional  relational  operator-; 

d .  Ex  amp 1 e ( s )  : 

(1)   ?>  (2  <  33  (2)   ?>  (2  >=  33 

true  -false 
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D.  LOGICAL  OPERATORS 

1 .   Con junct i_gn_^  5i5 JyOStiQQj.  b!g3^t i_gn 

a.  Syntax:         (;<  andsign  y)   or  (x  and  y) 

(x  orsign  y>    or  (x  or  y) 
(not  x) 

b.  Input (s> :      boolean (s) 
Output:        boolean 

c.  Description:   Conventional  logical  operators. 

d .  Ex  amp 1 e ( s ) : 

(1)  ?>     (true    andsign    trueD 

true 

(2)  ?>    ( (2    <    3)    or     (2    >    3: 

true 

(3)  ?>       (not     (3    =    3: 

■false 

E.  SET  OPERATORS 

1 .  !!!a>ii!DyfDj.  diQio}yQ» 

a.  Syntax:         (max  s) 

(min  s) 

b.  Input (s) :      numeric  set 
Output:        number 

c.  Description:  Returns   the   maximum   or   minimum 

element    of    the    input     set, 
respect i  vel y. 

d.  Example (s)  : 

(1)  ?>  (max  (set  4  8  2  10  93 

10 

(2)  ?>  (min  (set  4  8  2  10  9: 
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2.  Beiatignai  Sgrtj.  Sgrt 

a.  Syntax:         (rsort  s) 

(sort  s) 

b.  Input (s) :      numeric  set 
Output:        relation 

c.  Description:   The  input  set  is  sorted  in  ascend- 

ing order  and  converted  into  a 
sequence  -For  rsort,  and  a  list  for 
sort. 

d.  Example (s): 

(1)  ?>  (rsort  (set  4  8  2  10  9: 

(rel  (2  4)  (4  8)  (8  9)  (9  10)  ) 

(2)  ?>  (sort  (set  4  8  2  10  9] 

(rel  (1  2)  (2  4)  (3  8)  (4  9)  (5  10)) 

3.  EleOJ^Qt  SeJ^ectign 

a.  Syntax:         (epsilon  r) 

b.  Input (s):      set  or  relation 
Output:        anything 

c.  Description:   Returns   the   -First  element  o-F  the 

input  provided. 

d .  Ex  amp 1 e ( s ) : 

(1)  ?>  (epsilon  (set  4  8  2  10  9: 

4 

(2)  ?>  (epsilon  (rel  (1  :  2)  (2  :  3D 

(1  2) 

4-   yniayg  iisment  Sel^ectign 

a.  Syntax:         (theta  s) 

b.  Input (s):      unit  set 
Output:         anything 

c.  Description:   Extracts   the   single   member  o-F  a 

unit  set  and  returns  it. 

d.  Example (s):    ?>  (theta  (set  "dog"] 

dog 
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5-  Uolay^  Set 

a.  Syntax:         (uset  r) 

b.  Input (5):      set  or  relation 
Output:        set  or  relation 

c.  Description:   Eliminates  redundant  elements  -from 

the  input  structure  provided. 

d.  Example (s):    ?>   (uset  (set  4  8  2  4  10  93 

(set  4  S  2  10  9) 

6.  Intersect i.gnj_  Unign  and  Set  Difference 

a.  Syntax:         (s  cap  r) 

(s  cup  r) 
(s  \  r) 

b.  Input (s):      set  or  relation 
Output:        set  or  relation 

c.  Description:   Conventional  set  operations. 

d .  Ex  amp 1 e ( s ) : 

(1)  ?>  ((set  12  3)  cap  (set  2  3  43 

(set  2  3) 

(2)  ?>  ((set  12  3)  cup  (rel  (1:2)   (2  :  Zl 

(set  12  3  (12)  (2  3)) 

(3)  7>  ((set  1  2  3)  \  (set  2  3  43 

(set  1) 

(4)  ?>  ( (set  12  3)  \  (set  1  2  33 

empty 

7.  Cartesian  Product 

(s  cart  r) 

set  or  relation 
relati  on 

None  required. 


>  ((set  1  2)  cart  (set  5  63 
(rel  (15)   (16)   (2  5)   (2  6)  ) 


a. 

Syntax : 

b. 

Input (s) : 

Output: 

c. 

Descr i  pti  on : 

d. 

Example (s) : 
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a.  Syntax:         (size  r) 

b.  Input (s):      set  or  relation 
Output:         integer 

c.  Description:   Returns   the  number  o-f  elements  in 

the  input  set  or  relation. 

d .  Ex  amp 1 e ( s ) : 

(1)  ?>  (size  (set  4  8  2  10  9: 

5 

(2)  ?>  (size  (rel  (1  :  3)  (3  :  5)  (5  :  71 


9.   IJSffibershi^gj^  NoQQismbershiE 

a.  Syntax:         (x  member  r) 

(x  nomem  r) 

b.  Input (s) :      anything;  set  or  relation 
Output:        boolean 

c.  Description:   Verifies   i -f   x  is   or   is   not   a 

member    o-f   the   input    set    or 
relation. 

d.  Example (s) : 

(1)  ?>  (2  member  (set  1  2  33 

true 

(2)  ?>  ((1  :  2)  nomem  (rel  (1:2)  (2  :  3) 3 

-false 

10.       IfDBCOB^C    Sub  set  j_    EcQE^!!    Subset 

a.  Syntax:  (s     ! subset    r) 

(s    subset    r) 

b.  Input (s) :      set  or  relation 
Output:         boolean 

c.  Description:   Verifies  that  all  members  o-f  s  a.v-^ 

members  o-f  r.  The  cardinality  o-f 

5     must    be  less    than    the 

cardinality   o-f  r   for   a   proper 
subset. 


ll 


d.   Example (s) : 

(1)  ?>  ((set  12  3)  ! subset  (set  12  3): 

true 

(2)  ?>  ((set  12  3)  subset  (set  12  3: 

-False 

(3)  ?>  (rel  (1  :  2))  subset  (set  4  (1  :  2)  5: 

true 


F.   RELATION  OPERATORS 
1 .  Sel^ec  t  ign 

Syntax : 


a. 


b. 


Input (s) : 
Output: 

Description: 


(t  sel  X) 

anything;  relation 
anything 


Given  the  le-ft  member  o-f  a  rela- 
tion, X,  the  associated  right 
member  o-f  the  first  occurence  o-f  x 
in  t  will  be  returned. 


Example (s) : 

?>    t    ==     (rel 
?>     (2    sel     : 


(1 


2)      (2 


;)    (1 


;)    (2 


4) : 


QoQ^tliy^tign 

a.  Syntax: 

b.  Input (s) : 
Output: 

c.  Description: 


(t  #  u) 

rel ations 
rel ati  on 

Constructs  a  table  (relation) 
which  relates  each  common  le-ft 
member  o-f  t  and  u,  to  a  list 
created  by  selecting  the 
respective  right  members  -from  t 
and  u  by  using  the  common  le-ft 
member  as  a  target.  When  creating 
the  list,  the  right  member 
associated  with  the  first 
occurence  of  the  target  is  used. 
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Example (s) : 


>    t    ==    (rel     (1:2)     (2    :    3) 

(1     : 

3)     (2 

>    u   ==    (rel     (1:8)     (2:9) 

(3    : 

10)  : 

>    (t   #  u: 

(rel     (1     (rel     (12)     (2    8))) 

(2     (rel     (13)     (29)))) 

4)  3 


3.  Converse 

a.  Syntax:         (cnv  t)   or  (t  sup  -1) 

b.  Input (s):      relation 
Output:        relation 

c.  Description:   Returns  a  table  where  each  element 

o-F  table  t  has  the  le-ft  and  right 
member  inverted.  See  special 
operator  section  -for  other  uses  o-f 
the  'sup'  syntax. 

d.  Example (s)  : 

?>  t  ==  (rel  (1:2)  (2:3)  (1:3)  (2  :  4)  j 
?>  (cnv  t: 
(rel  (2  1)  (3  2)  (3  1)  (4  2)  ) 

4.  Extensignal^  Qurryj.  Extensignal,  yncurry 

a.  Syntax:         (cur  t) 

(unc  t) 

b.  Input (s) :      relation 
Output:         relation 

c.  Description:   Given   an  extensional   representa- 

tion o-F  an  in-Fix  -function  in 
either  curried  -form  or  uncurried 
form,  these  operators  will  convert 
one  -Form  to  the  other.  Each 
element  in  the  uncurried  form  o-f 
such  a  table  consists  o-F  the 
-function  argument  list  paired  with 
the  result  o-F  applying  the 
-Function  to  these  arguments.  In 
curried  -Form,  the  resulting  table 
is  the  equivalent  o-F  -Fixing  the 
left  member  of  the  infix  operator. 
This  left  member  is  paired  with 
another  table  which  contains  all 
potential  right  members  paired   to 
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the    result    o-f    applying    the 
function  to  the  -Fixed  left  member. 


d .   Ex  amp 1 e ( 5 ) : 


Consider  a  portion  o-f  an  uncurried 
table  which  represents  the  '+' 
-function: 


?>  t  ==  (rel 

(  (1 

,  1)  :  2)  ((1  ,  2) 

:  3) 

(  (1 

,  3)  :  4)  ((2  ,  1) 

:  3) 

(  (2 

,  2)"  :  4)  (  (2  ,  3) 

:  5) 

?>  (cur  t: 

(rel  (1  (rel 

(1 

2)  (2  3)  (3  4>  )  > 

(2  (rel 

(1 

3)   (2  4)  (3  5)))  ) 

Qc^ered  Union 

a.   Syntax: 

(t  ;  u) 

b.   Input (s) : 

rel ations 

Output: 

relation 

Description: 


Creates  a  table  where  all  elements 
o-f  t  Are  added  to  u,  replacing  any 
corresponding  elements  already 
there. 


d .   Ex  amp 1 e ( s ) : 


>  t  ==  (rel  (1:2)  (2  :  3)  (3 

>  u  ==  (rel  (2  :  4)   (3  :  6)  (4 

>  (t  ;  u] 

(rel  (12)  (2  3)   (3  4)  (4  7)  ) 


4)  1 
7)  3 


Primitive  Relative  Product 


Syn- 


(t 


u) 


Input (s) : 
Output: 

Description: 


rel ations 
rel at ion 


For   an   element  in  t,   its 
member   is  used  as  a  target 
producing     a    set    o-f 
associated  with  the   target. 
elements   -for  the  resulting 
a.re       created   by  pairing  the 
member   of  the  element  in   t 
each   value   in   this   set. 
resulting   table  contains  all 


r  i  ght 

in   u , 

val ues 

New 

table 

left 

wi  th 

The 

the 

elements    created   by   the   above 
process  for  each  element  in  t. 


/ 
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d .   Ex  amp 1 e ( s ) : 


?>  t  ==  (rel  (1:2)  (2:3): 

?>  u  ==  (rel  (2  :  4)  (2  :  8)  (3  :  6)  (3  :  12)] 
?>  (t  i  u: 
(rel  (14)  (1  8)  (2  6)  (2  12)  ) 

7.  All A  UQit  image 

a.  Syntax:         (y  all  t) 

( t  un  i  mg  x ) 

b.  Input(s):      anything;  relation    (all) 

relation;  anything   (unimg) 
Output:        set 

c.  Description:    'all'  returns   a  set  of   all   le-ft 

members    related   to   the   target 

right  member,     y.     Likewise, 

'unimg'  returns  a  set  o-f  all  right 

members  related  to  the  target  left 

member,  x. 

d.  Example (s) : 

Let  t  =  (rel  (1  :  2)  (2  :  3)  (1  :  3)  (2:4)) 

(1)  ?>  (3  all  t: 

(set  2  1) 

(2)  ?>  (t  unimg  23 

(set  3  4) 

8.  DgmaiQj^  B^nge 

a.  Syntax:         (dom  t) 

(rng  t) 

b.  Input (s):      relation 
Output:         set 

c.  Description:    'dom'  returns  all  left  members   of 

the  relation  t,  and  'rng'  returns 
all  right  members  of  t.  Neither 
of  these  operators  eliminate 
redundant  elements. 
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d .   E>;  amp  1  e  ( s )  : 


Consider  the  relation  shown 
graphically  in  Figure  C-1  and  its 
input  -form  here: 


t  ==  (rel  (1  :  2)  (2  :  4)  (2  :  5)  (3  :  5)  (5 
(5  :  6)   (7  :  6)  (8  :  7)   (8  :  8)  (9 


5) 
7)  ) 


Figure    C-1       Arrow    Diagram    -for    Relation    t 


(1)  ?>     (dom    t: 

(set    12235    5    788    9) 

(2)  ?>     (rng    t3 

(set    245556678    7) 


j[ni_ti_al_    MemberSj,    Termi_nal_    Members 


Syntax 


(init    t) 
(term    t) 


b. 


Input (s) : 
Output: 


rel ati  on 
set 


Description: 


Given  a  table  which  represents 
some  relation,  the  initial  members 
ars  those  which  3.re  le-ft  members 
o-f  the  relation,  but  not  right 
members.  Conversely,  the  terminal 
members  Ar&  those  which  3.re  right 
members,  but  not  le-ft  members  o-f 
the  relation.  'init'  returns  the 
intial  members  of  a  relation,  and 
'term'  returns  the  terminal 
members. 


d.  EKample(s):   Using  the  relation  in  Figure  C-1, 


>  (init  t: 
(set  1  3  9) 


>  (term  tl 
(set  4  6) 
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10. 


11 


Members 

a.  Syntax: 

b.  Input (s) : 
Output: 

c.  Description: 


d 


(mem  t) 

relation 
set 

Returns  a  set  ai  all  le-ft  and 
right  members  o-f  the  relation  t. 
Because  this  operator  is  de-fined 
in  terms  o-f  the  domain,  range  and 
union  opertors,  redundant  elements 
may  be  le-ft  in.  The  union  between 
the  domain  and  range  of  t  will 
leave  any  redundant  elements  in 
the  range  in  the  result.  See 
re-ference  ##  -for  more  in-formation 
on  how  LISP  implements  union. 


Example  (s):   Using  the  relation  -from  Figure  C-1  , 


( mem    t 1 
(set    1 


9245556678    7) 

Lsft    llj^mberj.    Bight    Memberj.    Member 

a.       Syntax:  (x    Lm    t) 

(x    Rm    t) 
(x    Mm    t) 


b.  Input (s) : 
Output: 

c.  Description: 


anything;  relation 
boolean 

Verifies  if  x  is  a  left,  right,  or 
either  a  left  or  right  member  of 
t,  respectively. 


d.   Example (s) : 

Let  t  =  (rel  (1 

(1)   ?>  (3  Lm  t3 
true 


2)  (3  :  4)  (5:6)) 

(2)   ?>  (8  Mm  t: 
false 


(3)   ?>  (5  Rm  t: 
false 


(4)   ?>  (5  Mm  t: 
true 
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12.   Le£t  Uni_ya]^entj^  Biabt  yQlyal^entj.  Bi^-uni^valent 

a.   Syntax:         dun  t) 

(run  t) 
(bun  t) 


b.  Input (s) : 
Output: 

c.  Description: 


d .   Ek  amp 1 e ( 5 ) : 


(1)   ?>  dun 
false 


relation 
boolean 

A  le-ft  univalent  relation  is  one 
in  which  each  element  in  the 
domain  is  unique.  In  other  words, 
no  two  different  right  members  can 
have  the  same  left  member. 
Likewise,  a  run  univalent  relation 
is  one  in  which  every  right  member 
is  unique.  Therefore,  it  follows 
that  a  bi— univalent  relation,  also 
known  as  a  isomorphism  is  one  that 
has  both  unique  left  and  right 
members.  These  operators  deter- 
mine if  the  relation  is  what  is 
requested. 


(rel  (1 


2)  (2 


3)  (1 


;)  1 


(2)  ?>  (run  (rel  (1:2)  (2:3)  (1:5): 

true 

(3)  ?>  (bun  (rel  (1  :  2)  (2  :  3)  (3  :  4)] 

true 


SEQUENCE  OPERATORS 


1 .  First  Member  J.  lQitial_  Seguence 


a.   Syntax: 


(alpha  t) 
(ALPHA  t) 


b.  Input (s) : 
Output: 

c.  Description: 


sequence 
anything; 


sequence 


'alpha'  returns  the  first  element 
of  the  sequence  s,  while  'ALPHA' 
returns  the  entire  sequence  except 
the  last  element. 
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d .   Ex  amp 1 e ( s ) : 

(1)  ?>  (alpha  (seq  12  3  4  5] 

1 

(2)  ?>  (ALPHA  (seq  1  2  3  4  53 

(rel  (1  2)  (2  3)  (3  4)  ) 

2.  Last  Member  J.  EiQ^i  Seguence 

a.  Syntax:   t      (omega  t) 

(OMEGA  t) 

b.  Input (s) :      sequence 

Output:         anything;  sequence 

c.  Description:   'omega'   returns   the  last  element 

in  the  sequence  t,  while  'OMEGA' 
returns  the  entire  sequence  except 
the  -first  element. 

d .  Ex  amp 1 e ( s ) : 

(1)   ?>  (omega  (seq  1  2  3  4  53 


(2)   ?>  (OMEGA  (seq  12  3  4  5: 
(rel  (2  3)  (3  4)  (4  5)  ) 


Cons  Le£tj_  Cons  Right 

a.  Syntax:         (x  cl  t) 

(t  cr    x) 

b.  Input (s):      x  =  anything;  t  =  sequence 
Output:         sequence 

c.  Description:   Any    data  item   is  added   to   the 

beginning   (le-Ft)   or  to   the   end 
(right)  o+  the  sequence  t. 

d .  Ex  amp 1 e ( s  > : 

(1)  ?>  (1  cl  (seq  2  3  4  5] 

(rel  (12)  (2  3)   (3  4)  (4  5)) 

(2)  ?>  ( (seq  12  3  4)  cr  53 

(rel  (12)  (2  3)  (3  4)  (4  5)  ) 
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^-   !!!!i.Qi!I!i2.g  Seguence 

a.   Syntax:         (mu  t) 


b.  Input (s) : 
Output: 

c.  Description: 


Example (5) : 


relation 
sequence 

This  operator  eliminates  redundant 
edges  from  a  relation  which  has  as 
its  underlying  structure  a 
sequence.  This  type  o-f  structure 
can  be  obtained  as  a  result  o-f 
some  of  the  higher  order  operators 
discussed  in  sections  K  and  L. 
Care  must  be  exercised.  If  t  does 
not  originate  from  a  true 
sequence,  the  computation  may  not 
halt. 


>    t    ==     (rel 

(3    : 

4) 

(3 

:     6)      (3    :     7) 

(3    : 

2) 

(4    : 

6) 

(4 

:     7)      (4    :     2) 

(6    : 

7) 

(6    : 

2) 

(7 

:     2)  1 

>     ( mu    tl 

(rel     (3    4) 

(4    6) 

(6 

7) 

(7    2)  ) 

5-  Seguence  of  Seguences  to  Matri.K 
a.   Syntax:         (ssm  t) 


c. 


Input (s) : 
Output: 

Description; 


Exampl e (s) : 
?>  t  ==  (seq 


relation 
relation 

Given  a  relation  in  the  form  of  a 
sequence  of  sequences,  this 
operator  converts  it  into  a 
relation  which  represents  a 
matrix.  The  left  member  is  a  list 
of  the  column  and  row  number,  and 
the  right  member  is  the  value  at 
that  position. 


(seq  10  213  313) 
(seq  4(3  50  60) 
(seq  70  80  90) 1 
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7>     (55m 

t] 

(rel 

(  (rel 

1 

)     (2 

1)  ) 

10) 

(  (rel 

1 

>     (2 

2)  ) 

20) 

(  (rel 

1: 

)     (2 

■J  /  / 

30) 

(  (rel 

2, 

)     (2 

1)  ) 

40) 

(  (rel 

21 

>     (2 

50) 

(  (rel 

-7 

>     (2 

3)  ) 

60) 

(  (rel 

-T  1 

>     (2 

1)  ) 

70) 

(  (rel 

.J> 

>     (2 

2)  ) 

80) 

(  (rel 

T  ' 

>     (2 

3)  ) 

90)  ) 

*^-  S^Sysnce  to  Arra^ 
a.   Syntax: 


b. 


Input (s) : 
Output: 


(t  sa  n) 

sequence;  positive  integer 
relation  ia^rra^y) 


Description:   Converts   the  sequence  t   into   an 
array  indexed  starting  with  n. 

Example (s) : 

?>  ( (seq  10  20  30)  sa  4D 
(rel  (4  10)  (5  20)  (6  30) ) 


H.   ARRAY  OPERATORS 

1 .   Array  to  Seguence 


b. 


Syntax : 

Input (s) : 
Output: 


(as  t) 

relation  {^.x-r^Ly^ 
relation  (sequence) 


Description:   Converts   the  values  o^^  the   giver 
Arra.y    into  a  sequence. 

Ex  amp 1 e ( s )  : 

>  (as  (rel  (1  :  10)  (2  :  20)   (3  :  30)  (4  :  40)] 
(rel  (10  20)   (20  30)  (30  40)) 
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2.  BCH^Y.    QoQcatenatign^ 


a.  Syntax:  _ 

b.  Input (5) : 
Output: 

c.  Description: 


Ex  amp 1 e ( s ) : 


(t  cat  u) 

relations  (arrays) 

relation   (array) 

Concatenates   u   to  t  by   altering 

the  indices  o-F  u  to  be  consecutive 

with  the  indices  o-F  t. 


10)  (2  :  30)  (3  :  30)  1 
40)   (2  :  50)  (3  :  60)  : 


>  t  ==  (rel  (1 

>  u  ==  (rel  (1 

>  (t  cat  ul 

(rel  (1  10)  (2  20)  (3  30)  (4  40)  (5  50)  (6  60)) 


a.  Syntax: 

b.  Input (s) : 
Output : 

c.  Description: 


(rev    t) 

relation     (array) 
relation     isirray) 

Returns   an  array  with  the   values 
reversed . 


Example(s):    Using  t  -from  the  example  above, 

?>  (rev  t: 
(rel  (1  30)  (2  20)  (3  10) ) 


I.   DATABASE  OPERATORS 
1  -   Database  Index 

a.  Syntax: 

b.  Input (s) : 
Output: 

c.  Description 


(x  index  d) 

X,  anything  (-field  name) 
d,  relation  (database) 
rel ation 

Returns  a  relation  which  pairs  the 
value  associated  with  -field  name 
X,  to  the  entire  record  that  the 
-field  name  was  found  in,  for  all 
records  in  d. 
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d.   Example (s):    Consider  the  following  database: 


dbl  = 


(set 

(rel 

("#" 

:  100) 

("name" 

(rel 

("#" 

:  101) 

(  "name" 

(rel 

("#"  . 

:  102) 

(  "name" 

(rel 

("#" 

:  103) 

("name" 

(rel 

("#"  ; 

:  104) 

("name" 

"Brown")  ("hours' 

"Mitton")  ("hours' 

"Benson")  ("hours' 

"Murnan")  ("hours' 

"Garcia")  ("hours' 


10) ) 

■  8)  ) 

.  16)) 

10)  ) 

12)  )  ) 

>  ("hours"  index  dbl 3 

(set  (10  (rel  (#  100)  (name  Brown)  (hours  10))) 


(8  (rel 

(16  (rel 

(10  (rel 

(12  (rel 


(#  101) 

(#  102) 

(#  103) 

(#  104) 


(name  Mitton) 

(name  Benson) 

(name  Murnan) 

(name  Garcia) 


(hours  8) ) ) 
(hours  16) ) ) 
(hours  10) ) ) 
(hours  12)))) 


Database  Select 


Syntax : 
Input (s) : 
Output: 
Description: 


(x  select  d) 

K,  anything  (-field  name) 
d,  relation  (database) 
-function 

Returns  a  -function  which  when 
given  a  predicate  selects  those 
records  -for  which  the  predicate  is 
true  and  returns  a  relation  with 
those  records. 


Ex amp  1 e  (s)  : 


Suppose    the    user   wan 
records   which   have   an 
-field    equal    to   10   f 
database,  dbl,  used  above 
argument  to  the  -functiona 
by  the  'select'  operator 
the  predicate,   (rsec  =  1 
predicate   compares   the 
the  X  field  with  the  valu 
true,   the   record  is  inc 
the   resulting   set. 


ted 


1  1 


'ho 

urs  ' 

r 

Dm 

the 

. 

Thu 

s  th 

1 

izrs 

ated 

w 

DUl  d 

be 

0 

)  = 

This 

v 

al  ue 

of 

e 

10. 

If 

1 

uded 

in 

(("hours"  select  dbl) 
Bt     (rel  (#  100)   (name 

(rel  (#  103)   (name  Murnan)  (hours  IS))) 


(rsec  =  10: 
Brown)   (hours  10)) 
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O^t^base  Joi.n 

a.  Syntax: 

b.  Input (s) : 
Output: 


c. 


db2  = 


Description: 


d.   Example (s) 


(x  join  dl ) 

X,   anything  (-field  name) 
dl ,  relation  (database  list) 
relation   (database) 

This  operator  performs  a  natural 
join  on  two  databases,  combining 
all  the  -fields  o-f  both  databases, 
based  on  the  equality  o-f  the 
values  in  the  -field  -speci-fied  -  x. 

Consider  the  database,  db 1 ,  in  the 
'index'  example  and  the  additional 
database,  db2,  given  below: 


(set 

(rel 

("#"  . 

:  100) 

("age" 

(rel 

('•#" 

:  101) 

("age" 

(rel 

("#"  : 

■  102) 

("age" 

(rel 

(■•#"  . 

:  103) 

("age" 

(rel 

("#"  : 

104) 

("age" 

32)  ("office" 

27)  ("office" 

21)  ("office" 

45)  ("office" 

37)  ("office" 


"D3") ) 

"j!i4"  )  ) 

"  C 1  "  )  ) 

M^   /  ) 

"B8" ) ) ) 


("#"  join  (list  dbl  db2) 2 


(set 

(rel 

(name 

Garcia) 

(hours 

12) 

(# 

104) 

(age 

37) 

(of f  i  ce 

BS )  ) 

(rel 

(name 

Murnan) 

(hours 

10) 

(# 

103) 

(age 

45) 

(of f  i  ce 

A2)  ) 

(rel 

(name 

Benson) 

(hours 

16) 

(# 

102) 

(age 

21) 

(office 

CD  ) 

(rel 

(name 

Mitton) 

(hours 

8) 

(# 

101) 

(age 

27) 

(of f  i  ce 

A4)  ) 

(rel 

(name 

Brown ) 

(hours 

10) 

(# 

100) 

(age 

32) 

(office 

D3)  )  ) 

K.   HIGHER  ORDER  OPERATORS  -  RETURNING  FUNCTIONS 


1  •  BCL^Y  B^^y^t i^gn^ 

a.  Syntax: 

b.  Input (s) : 
Output: 

c.  Description: 


(f  red  x) 

function:  anything 
function 

Given  a  function  f ,  which  will 
operate  on  the  data  of  an  arr 3.y. 
and  a  starting  point,  x,  this 
operator  produces  a  function  which 
reduces  an  ArrAy.  When  executed, 

the  result  is  set  to  the  starting 
point,  X.  f  is  applied  to  the 
result   and   the  first  element   of 
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data  in  the  aLrra^y,  producing  a  new 
result.  -f  continues  to  be  applied 
as  above  until  all  data  elements 
have  been  utilized  as  input.  The 
result  is  then  returned. 

d.   E;<ample(s):    Consider     the    de-finition    -for 

factorial : 

?>  -Fac  X  ==  (((op  times)  red  1)  (li  strange  1  to  k1 
?>  (-Fac  S: 
40320 

CgmgQsi_ti_gn 

a.  Syntax:         (fog) 

b.  Input (s):      functions 
Output:         function 

c.  Description:   Produces   a   function   which   when 

given  an  appropriate  argument  will 
apply  f  to  the  result  of  applying 
g  to  that  argument. 

d.  E;<ample(s):    Consider   another   definition   for 

the  squaring  function: 

?>  sqr  ==  (times  o  DELTA) 
?>  (sqr  4) 
16 

a.  Syntax:         (curry  f) 

(uncurry  f) 

b.  Input (s) :      function 
Output:         function 

c.  Description:   These   two   operators  ars    used   to 

convert  between  the  two  types  of 
infix  f  un c  t  i  on s .  An  infix  f  un c - 
tion  which  takes  a  single  argument 
in  the  form  of  a  list  is  in 
uncurried  form.  When  such  a 
function  is  curried,  it  produces  a 
functional,  which  will  produce 
another  function  when  given  one  of 
the  two  arguments  that  arB 
normally  required.   This  resultant 
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■function  -fixes  this  argument  and 
creates  a  -function  which  takes  any 
other  valid  argument  and  returns 
the  same  result  as  i -f  the 
uncurried  version  had  been  given 
both  arguments. 


Example (s) : 


?>  sum  ==  (op  +]  -C*  uncurried  form  *> 

?>  add  ==  (curry  sum3 

?>  -f  ==  (add  33 

?>  (sum  (list  3  5: 

8 

?>  (-f  53 
o 

Exten5i_Qn 

a.  Syntax:         (t  extend  -f ) 

b.  Input  (s)  :      relation;  -function 
Output:        -functional 

c.  Description:   Produces   a  -functional  which   when 

given  an  argument  -first  checks  to 
see  i-f  it  is  the  domain  o-f  t.  If 
so,  its  right  member  is  returned, 
else  the  function  f  is  applied  tc 
the  argument. 

d.  Example (s):    Suppose   the   user  wanted  to   work 

with  a  subrange  of  the  positive 
integers,  say  1  to  50,  so  that  the 
successor  of  the  argument  would  be 
returned  if  the  argument  was  in 
this  subrange,  and  an  error 
message  would  be  returned  if  it 
was  not: 

(1)  ?>  t  ==  (seqrange  1  to  501 

7>  f  X  ==  "Error  —  not  within  range" 
?>  subrange  ==  (t  extend  fl 
?>  (subrange  253 
26 

(2)  7>  (subrange  553 

Error    -    not  within  range 
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I^sgati^gn  g£  a  Functi_gn 

a.  Syntax:         (wig  p) 

b.  Input  (s)  :      boolean  -function 
Output:        function 


c.  Description:   Returns   a  -function  which   negates 

the  result  o-f  the  input  boolean 
function. 

d.  EKample(s):    Consider   a  function  to   determine 

if  a  numeric  argument  is  within 
the  subrange  19  to  20,  and  then 
the  opposite,  a  function  to 
determine  if  the  argument  is 
outside  the  range: 

?>  in-range  x  ==  ( (x  >=  10)  and  (x  <=  203 
?>  out— of— range  ==  (wig  in— range] 
?>  (out -of -range  25 H 
true 

E^C^llsiiDQ  2£  EyQ^ti-QQS 

a.  Syntax:         (f  ! 1  g) 

b.  Input (s):      functions 
Output:         function 

c.  Description:   Produces   a  function  from  the   two 

input  functions  which  when  given 
an  argument  list,  returns  a  list 
of  the  results  of  applying  f  to 
the  first  member  of  the  argument 
list  and  g  to  the  last  member  of 
the  argument  list. 

d.  Example(s):    Consider   a  different  approach   to 

the  in— range  function  from  the 
last  example: 

?>  blist  ==  (((rsec  >=  10)  !!   (rsec  <>  20))  o  DELTA: 
?>  (blist  15: 

?>  (rel  (1  true)  (2  true)) 
7>  in— range  ==  (and  o  blist: 
?>  (in— range  153 
true 
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~^  •       ytli.l.e  LogB 

a.  Syntax:  (f  while  p) 

b.  Input  (s):  -function;  boolean  -function 
Output:  -function 


c.  Description:   Produces   a   function   which   when 

given  an  argument  will  -first  test 
the  predicate  with  the  argument. 
I-f  the  predicate  succeeds  then  -f 
is  applied  to  the  argument.  The 
result  of  this  application  is 
passed  to  the  predicate  and  if  the 
predicate  again  succeeds,  f  is 
applied  to  this  result.  This  cycle 
continues  until  the  predicate 
fails.  If  the  predicate  fails  on 
the  first  attempt,  the  original 
argument  is  returned. 

d.  EKample(s):    Consider  a  definition  for   modulo 

ari  thmetic: 

modaux  x  ==  (^r'ssr    —  x)  while  (  (rsec  >=  0)  o  (rsec  -  x)I! 
mod  ==  ( (uncurry  modaux)  o  rev] 
(10  mod  41 


y^i.y^    °£    ^    ijlQdej^    Data    Structure 

a.  Syntax:         (upsilon  f) 

b.  Input (s):      function 
Output:         function 

c.  Description:   Creates   a  function  which  takes   a 

data  structure  and  returns  the 
value  of  the  node  selected  by  f. 

d.  Example(s):    Suppose  the  user  wanted  a  function 

which  would  return  the  value  of 
the  first  node  of  a  given  data 
structure.  Consider  a  RPL  data 
structure  for  a  sequence: 
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?>  S  ==  (list  (list  3  4  -2  6  7  -1  2  -4) 

(seqrange  1  to  31 
?>  val  S 
(rel  (1  (rel  (1  3)  (2  4)   (3  -2)  (4  6)  (5  7) 
(6  -1)  (7  2)  (8  -4)  ) 
(2  (rel  (1  2)  (2  3)  (3  4)  (4  5)  (5  6) 
(6  7)  (7  8)  )  ) 
?>  -first  ==  (upsilon  alpha] 
?>  (-First  S: 


*^-   Qeerate  on  Dataj^  Data  Structure 

a.  Syntax:         (delta  f) 

b.  Input  (s):      -Function 
Output:        function 

c.  Description:   Creates    a   -function   which   will 

operate  on  the  data  part  o-f  the 
RPL  data  structure.  There-fore  the 
-function  -f  must  accept  as  a  valid 
argument  the  relation  which 
represents  the  data  part  of  the 
data  structure.  The  resulting 
-function  takes  a  data  structure  as 
an  argument,  applies  -f  to  the  data 
component ,  and  returns  the 
modi-fied  data  structure. 

d.  EKample(s):    Suppose   the  user  wanted  to  add   1 

to  every  data  element  o-f  the  data 
structure  used  in  the  last 
example: 

?>  -f  ==  (Isec  (hd  (:  bar)  (  (rsec  +  1)  o  tl  )  )  img: 
?>  addl  ==  (delta  -f  D 
?>  (addl  S: 

(rel  (1  (rel  (1  4)  (2  5)  (3  -1)  (4  7)   (5  S) 

(6  0)   (7  3)  (8  -3)  ) 

(2  (rel  (1  2)   (2  3)  (3  4)   (4  5)   (5  6) 
(6  7)   (7  8))  ) 

10.   QBec^te  on  Formj.  Data  Structure 

a.  Syntax:         (phi  f) 

b.  Input  (s)  :      -function 
Output:         -function 


c.  Description:   Creates    a   -Function   which   will 

operate  on  the  form  part  of  the 
RPL  data  structure.  Therefore  the 
function  f  must  accept  as  a  valid 
argument  the  relation  which 
represents  the  form  part  of  the 
data  structure.  The  resulting 
function  takes  a  data  structure  as 
an  argument,  applies  f  to  the  form 
component ,  and  returns  the 
modified  data  structure. 

d.  Example(s):   Using   the  data  structure   defined 

preiously,  consider  a  function 
which  will  eliminate  the  first 
node  of  the  data  structure: 

?>  rest  ==  (phi  OMEGA: 
?>  (rest  S: 
(rel  (1  (rel  (1  3)  (2  4)  (3  -2)  (4  6)   (5  7) 
(6  -1)  (7  2)  (8  -4)  ) 
(2  (rel  (2  3)  (3  4)  (4  5)  (5  6) 
(6  7)  (7  3))  ) 

1 1 .   l0]^9E  9f.  ^  O^ta  Structure 

a.  Syntax:         (PI  f) 

b.  Input (s):      function 
Output:        function 

c.  Description:   Creates   a   function,    that   when 

given  a  data  structure,  applies  f 
to  all  values  in  the  data  part  of 
the  structure  and  returns  the 
modified  data  structure. 

d.  Example(s):    Now,   to   add  1  to  every  value   as 

done  in  the  'delta'  example,  the 
user  simply  writes: 

7>  addl  ==  (PI  (rsec  +1): 
?>  (addl  S: 
(rel  (1  (rel  (1  4)  (2  5)  (3  -1)  (4  7)  (5  8) 
(6  0)  (7  3)  (8  -3)  ) 
(2  (rel  (1  2)   (2  3)   (3  4)   (4  5)   (5  6) 
(6  7)   (7  8))  ) 
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HIGHER  ORDER  OPERATORS  -  RETURNING  DATA 

1.  Ei.l.tS!liQ3  Seguences 

a.  Syntax:         (p  xi  t) 

b.  Input (s):      p,  function  (boolean) 

t,  relation  (sequence) 
Output:        relation  (sequence) 

c.  Description:   Filters  the  relation  t,   using  the 

predicate,  p.  Reconnects  nodes 
that  could  be  lost  by  the  normal 
filtering  discussed  later  in  this 
section.  Used  as  a  part  of  the 
filtering  function  for  data 
structures,  is  discussed  next. 

d.  Example (s):    Suppose    the    user    wanted    to 

eleminate  the  negative  nodes  of 
the  below  sequence: 

?>  s  ==  (seq  3  4-267-12-4: 
?>  ( (rsec  >=  0)  xi  s^ 
(rel  (3  4)   (4  6)  (6  7)  (7  2)  1 

2.  Eil£sri.ng  Data  Structures 

a.  Syntax:         (p  PHI  S) 

b.  Input (s):      p,  function  (boolean) 

S,  relation  (data  structure) 
Output:         relation  (data  structure) 

c.  Description:   Extends   the   'xi'   functional   to 

work  on  RPL  data  structures.  Note 
that  the  data  part  is  not  changed, 
only  the  form  part  is  filtered. 

d.  Example(5):    Consider   the  sequence  used  in  the 

'xi '  example  as  a  RPL  data 
structure: 

?>  S  ==  (list  (list  3  4  -2  6  7  -1  2  -4) 

(seqrange  1  to  8) 1 
?>  ( (rsec  >=  0)  PHI  S: 

(rel   (1  (rel  (1  3)  (2  4)  (3  -2)  (4  6) 

(5  7)   (6  -1)   (7  2)   (8  -4)  )  ) 

(2  (rel  (1  2)   (4  5)   (2  4)   (5  7)))  ) 

Note:  Sequence  order  doesn't  matter  in  the  form  part. 


Fi_l_teri_ng  Rslatigns 

a.  Syntax:         (p  filter  t) 

b.  Input  (s):      boolean  -function;  relation 
Output:        relation 

c.  Description:   Eliminates  undesireable  nodes  from 

t  bv  applying  the  predicate  to 
each  element  of  t.  If  the 
predicate  succeeds,  the  element  is 
left  in  the  relation,  otherwise  it 
is  removed.  This  functional  is 
the  basis  for  the  restriction 
operators  discussed  next  in  this 
section. 

d.  Example(s):    Consider   the   same   sequence,   s, 

used  in  the  example  of  the  'xi 
operator.  This  will  illustrate 
that  this  filtering  method  can 
eliminate  valid  nodes  and  leave 
nodes  disconnected  in  the  case  of 
sequences: 

7>  val  s 

(rel  (3  4)  (4  -2)   (-2  6)   (6  7) 
(7  -1)  (-1  2)  (2  -4)  ) 
?>  p  X  ==  ((hd  x)  >=  0)  and  (tl  x)  >=  0)3 
?>  (p  filter  sD 

(rel  (3  4)  (6  7)  ) 

Restriction  -  Domai_nj_  B^DQ^a  i!Qt!2 

a.  Syntax:         (p  — >  t) 

(t  <-  p) 

(t  restr  p) 

b.  Input (s):      boolean  function;  relation 
Output:         relation 

c.  Description:   Returns  a  relation  which  restricts 

the  domain,  range  or  both  the 
domain  and  range,  respectively. 
This  is  accomplished  by  filtering 
the  table  using  the  predicate  p  on 
the  appropriate  members  of  each 
element  of  the  relation. 
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d.   E:<ample(5):    Consider  the  same  sequence  s,  used 

in  previous  examples: 

(1)  ?>  val  s 

(rel  (3  4)  (4  -2)  (-2  6)  (6  7) 
(7  -1)  (-1  2)  (2  -4)  ) 
?>  ( (rsec  >=  0)  ->  sJ 
(rel  (3  4)  (4  -2)  (6  7)  (7  -1)  (2  -4)) 

(2)  ?>  (s  <-  (rsec  >=    0)1 

(rel  (3  4)  (-2  6)  (6  7)  (-1  2)) 

(3)  ?>  (s  restr  (rsec  >=  0)1 

(rel  (3  4)  (6  7)  ) 

a.  Syntax:         (f  @  x) 

b.  Input  (s):      -function;  anything 
Output:        anything 

c.  Description:   Returns   the  result  of  applying   -F 

to  the  argument  x. 

d.  Example (s)  : 

?>  ((op  times)  @  (list  2  3) : 
6 

(t  @hat  x) 

relation  (table  o-f  functions) 

anything 

rel at i  on 

Produces  a  relation  which  pairs 
each  le-ft  member  of  the  input 
relation  to  the  result  of  apply- 
ing the  right  member  function  to 
the  argument  x . 

d.   Example(s):    Consider  the  following  simple  list 

of  functions: 

7>  t  ==  (list  (op  times)  (op  +)  (op  -)  (op  /)! 
?>  (t  ©hat  (list  4  31 
(rel  (1  12)  (2  7)   (3  1)  (4  1)) 


a. 

Syntax : 

b. 

Input (s) : 

Output: 

c. 

Descri  ption: 
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AOBllcatigQj.  Functional^  Structure 
a.   Syntax:         (t  !  x) 


b.  Input (s) : 
Output: 

c.  Description: 


relation 
relation 

The  input  table  to  this  -Functional 
must  have  a  domain  and  range  which 
consists  o-f  -functions  only.  The 
argument  ;<  must  be  valid  -for  all 
functions  contained  within  the 
table.  Each  element  o-f  t  will  be 
replaced  by  the  result  o-f  applying 
both  the  le-ft  member  and  right 
member  -functions  to  the  argument. 


a. 


d.   Example (s) : 

?>   t  ==  (rel  ((op  times)  : 

(op  / )  ) 

(  (op  +)  :  (op 

-)  )  ] 

?>  (t  !  (list  4  3: 

(rel  (12  1)  (7  1)) 

Image  g£  Sets 

a.  Syntax: 

b.  Input (s) : 
Output: 

c.  Description: 


(-f  img  t) 

-function;  relation 
set 

Returns  a  set  which  is.  the  result 
o-f  applying  -f  to  every  member  o-f 
the  set  or  relation  t. 


d .   Ex  amp 1 e ( s ) : 

?>  sqr  ==  (times  o  DELTAS 
?>  (sqr  img  (set  12  3  4  5] 
(set  1  4  9  16  25) 

Isomorohi^smj^  liD^S^  on  Relations 

a.   Syntax:         (-f  *  t) 


b.        Input (s) : 
Output: 


-function;     relation 
rel ation 
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c.  Description:   Returns   a  relation  which  has   the 

same  structure  as  the  original, 
except  that  each  element  is 
composed  o-f  the  result  o-f  applying 
-F  to  both  the  le-Ft  and  right 
member  of  the  element  o-f  t. 

d.  E;;ample(s):    Consider  again  the  'sqr'  -function: 

?>  (sqr  :|:  (seqrange  1  to  63 
(rel  (1  4)  (4  9)  (9  16)  (16  25)  (25  36)) 

10.   E-^lative  Product  J.  In  tension  a  1^ 

a.  Syntax:         (t  rp  f) 

b.  Input  (s):      -function 
Output:        relation 

c.  Description:   Returns   a   relation  which  is   the 

result  oi  applying  the  function  f 
to  every  right  member  of  the  input 
relation. 

d.  Example (s) : 

?>  t  ==  (li strange  1  to  53 
7>  (t  rp  (rsec  times  103 
(rel  (1  10)  (2  20)  (3  30)   (4  40)   (5  50)) 

11'   E"sl.ative  Product  Inyer sej^  lotensignal. 


Syntax:         (f  rpi  t) 

Input (s):      function 
Output:         relation 

Description:  Returns  a  relation  which  is  the 
result  of  applying  the  function  f 
to  every  left  member  of  the  input 
rel at i  on. 


d .   Ex  amp 1 e  ( s ) : 

?>  t  ==  (listrange  1  to  53 
?>  ((rsec  times  10)  rpi  t3 

(rel  (10  1)   (20  2)   (30  3)   (40  4)   (50  5)) 
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Restriction  ojF  a  Function 

a.  Syntax:         (s  restrict  i) 

b.  Input  (s):      relation  (set);  -function 
Output:        relation 

c.  Description:   Trans-forms   the   -function   into   a 

eKtensional  relation  (table)  based 
upon  the  set  o-f  domain  elements 
given  as  input.  It  pairs  each 
element  of  s  with  the  result  o-f 
applying  the  -function  -f  to  it. 

d.  EKample(s):    Suppose  the  user  wanted  a  table  o-f 

squares  -for  the  subrange  4  to  8: 

?>  s  ==  (setrange  4  to  83 
?>  sqr  ==  (times  o  DELTA: 
?>  (s  restrict  sqr] 
(rel  (4  16)  (5  25)  (6  36)   (7  49)   (8  64)) 


I 
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APPENDIX  D  -  INDEX  TO  RPL  OPERATORS 


Name 


Operator 


Page 


Addition  . 

+ 

All 

all 

Appl ication 

anything 

@ 

•functional  recor 

d 

@hat 

functional  struc 

ture 

1 

Array 

concatenat i  on 

cat 

-from  sequence 

sa 

reduction 

red 

reverse 

rev 

Array  to  sequence 

as 

Bi -univalent 

bun 

Cardinal i ty 

size 

Cartesian  product 

cart 

Composition 

■functions 

o 

repeat  using  sup 

erscription 

sup  n 

Concatenation  -  airraiy 

cat 

Conditional  -functional 

if 

Con juntion 

andsign , 

and 

Cons  le-ft  -  sequenc 

e 

cl 

Cons  right  -  sequen 

ce 

cr 

Construction 

# 

Converse 

relation 

cnv 

using  super scrip 

tion 

sup  - 1 

Curry 

extensional 

cur 

i  n ten si  cnal 

curry 

Data  definition 

list 

list 

list  range 

1 i  strange 

rel ation 

rel 

sequence 

seq 

sequence  range 

seqrange 

set 

set 

set  range 

setrange 

Data  structures 

f i 1 tering 

PHI 

image 

PI 

operate  on  data 

part 

delta 

131 

139 

157 

158 

158 

146 

145 

149 

146 

146 

142 

135 

1  -T5 

149 
127 
146 
126 
132 

144 

1  iii 


137 
127 

138 

150 

123 
123 
122 
122 
123 

1  '^T' 

123 

155 
154 
153 
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Data  structures,  cont. 

operate  on  -form  part 

value  o-f  a  node 
Database 

index 

join 

select 
Di-f  ^^erence 
Disjuntion 
Di  vi  si  on 
Domain 
Dupl i  cation 
Element  selection 
Empty  set  or  relation 
Equal i  ty 

Extension  o-f  a  relation 
Fi 1 tering 

data  structures 

rel ati  ons 

sequences 
Final  sequence 
First  member  —  sequence 
Formalization  functional 
Function  de-finition 

condi  ti  onal 

di  rect 

-fix  le-ft  argument 

fix  right  argument 

infix  to  prefix 

iteration 

whi le  loop 
Greater 

Greater  or  equal 
Head  —  elementary  pair 
Identity 
Image 

data  structure 

of  domain  element 

of  range  element 

relations  -  isomorphism 

sets 
Improper  subset 
Inequal i  ty 

Infix  to  prefix  conversion 
Intial  members 
Initial  sequence 
Intersection 
Isomorphism  —  relations 
Iteration  functional 
Last  member  —  sequence 
Left  member 


phi 
upsi Ion 

index 

join 

select 

orsign,  or 

divide  or  / 

dom 

DELTA 

epsi Ion 

empty 

extend 

PHI 

filter 

xi 

OMEGA 

alpha 

bar 

if 

f  unc 
1  sec 
rsec 
op 

iter 
whi  le 


hd 
I 

PI 

unimg 

all 

img 

! subset 

!  =  or  <  '. 

op 

i  ni  t 

ALPHA 

cap 

i  ter 

omega 

Lm 


154 
153 

147 

148 
147 
131 
132 
131 
140 
129 
133 
128 
129 
150 

155 
156 
155 
143 
143 
128 

126 
124 
125 
125 
125 
126 
152 
132 
132 
130 
130 

154 
139 
139 
159 
153 
136 
129 
125 
141 
143 
134 
159 
126 
143 
142 


I 
I 


162 


Le-Ft  section 
Le-ft  univalent 


Isec 
lun 


Less 

< 

Less  or  equal 

<  = 

List  de-finition 

list 

List  range  definition 

1 istrange 

Max  i  mum  -  set 

max 

Member 

Mm 

Members 

mem 

Membership. 

member 

Minimize  sequence 

mu 

Minimum  -  set 

min 

Mul ti pi i cation 

ti  mes 

Negation 

not 

Negation  -  -function 

wig 

Nortmembershi  p 

nomem 

Ordered  union 

m 

r 

Pair  Formation 

■ 

Pair  list 

» 

Paral 1  el i  ng 

1  1 

Product 

times 

Proper  subset 

subset 

Quoti  ent 

divide  or  / 

Range 

rng 

Reduction 

a.rray 

red 

Reflexive  transitive  closure 

sup  ** 

Relation  definition 

rel 

Relational  sort 

rsort 

Relative  product 

intensi  onal 

rp 

intensional  inverse 

rpi 

primitive 

1 
1 

Restricti  on 

domain 

y' 

of  a  function 

restri  ct 

range 

-> 

range  and  domain 

restr 

Reverse  SirrBy 

rev 

Right  member 

Rm 

Right  section 

rsec 

Right  univalent 

run 

Selection 

sel 

Sequence 

all  but  first  element 

OMEGA 

all  but  last  element 

ALPHA 

cons  left 

cl 

cons  right 

cr 

convert  to  3Lrra.y 

sa 

convert  to  matrix 

ssm 

def  i  ni tion 


seq 


125 
142 
132 
132 
123 
123 
133 
142 
141 
135 
144 

i.  -_*  J. 

132 
151 
135 
138 
130 
131 
151 
131 
136 
131 
140 

149 
127 

i  '^^ 

133 

159 
160 
139 

157 
160 
157 
157 
146 
142 
125 

136 

143 
143 
144 
144 
145 
145 

1  O*"? 
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Sequence,  cont. 

-filtering  xi  155 

■first  member  alpha  143 

-from  array  as  146 

last  member  omega  143 

minimize  mu  144 

range  definition  seqrange  123 

Set  de-finition  set  122 

Set  dif-ference  \  134 

Set  range  definition  setrange  123 

Sort  sort  133 

Subtraction  —  131 

Sum  +  131 

Superscription 

converse  sup  —1  127 

'  re-flexive  transitive  closure    sup  -**  127 

repeat  composition  f  sup  n  127 

transitive  closure  sup  +  127 

Tail  -  elementary  pair  tl  13S 

Terminal  members  term  141 

Transitive  closure  sup  +  127 

Uncurry 

extensional  unc  13S 

intensional  uncurry  150 

Union  cup  134 

Unique  element  selection  theta  134 

Unique  set  uset  134 

Unit  image  unimg  139 

Unit  set  un  131 

While  loop  while  152 
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APPENDIX  E  -  RPL  INPUT  FORM  SUMMARY 


TABLE  1.    Primitive  Extensional  Operations 


Name 


Old  Input  Form        New  Input  Form 


Publication  Form 


selection 

relative  product 

construction 

pair  formation 

union 

unit  set 

currying 

uncurrying 

unique  element  selection 

element  selection 

cardinality 

structure 

transitive  closure 

empty  set 


t  sel  X 
t{  u 

t  ,  bar  u 
X  :  y 
t  cup  u 
un  X 
cur  t 
unc  t 
theta  s 
(added) 
size  t 
str  t 
t  sup  + 
empty 


t  sel  X 
t  I  u 
t#u 
X  :  y 
t  cup  u 
un  X 
cur  t 
unc  t 
theta  s 
epsilon  t 
size  t 
(deleted) 
t  sup  + 
empty 


t  i  X 
t  I  u 
t  #  u 
X  :  y 
t  U  u 
un  I 
cur  t 
unc  t 

e  8 

e  t 
size  ( 
(deleted) 


TABLE  2.    Nonprimitive  Extensional  Operations:    Group  1 


Name 

Old  Input  Form 

New  Input  Form 

Publication 

Form 

pair  list 

(x,  y) 

(x,y) 

(^,  y) 

left  pair  section 

(x,) 

(deleted) 

(deleted) 

right  pair  section 

(,y) 

(deleted) 

(deleted) 

duplication 

DELTA  x 

DELTA  X 

Ax 

membership 

X  member  t 

X  member  t 

I  e  t 

nonmembership 

X  nomem  t 

X  nomem  t 

X   it 

improper  subset 

s  Isubset  t 

s  ! subset  t 

s  C    t 

proper  subset 

s  subset  t 

s  subset  t 

s   C    t 

equality 

s  =   t 

s  =    t 

s  =  t 

converse 

inv  t,  t  sup  -1 

cnv  t,  t  sup  -1 

cnv  t,  r^ 

domain 

dom  t 

dom  t 

duiii  t 

range 

rng  t 

rng  t 

mg  t 

members 

mem  t 

mem  t 

mem  t 

left  member 

Lm  (x,t) 

X  Lm  t 

X  Lm  t 

right  member 

Rm  (x,t) 

X  Rm  t 

I  Rm  t 

member 

Mm  (x,t) 

X  Mm  t 

X  Nfan  ( 

right  univalent 

run  t 

run  t 

run  t 

left  univalent 

lun  t 

lun  t 

lim  t 

bi-univalent 

bun  t 

bun  t 

bun  t 

initial  members 

init  t 

init  t 

init  t 

terminal  members 

term  t 

term  t 

term  t 

reflexive  transitive  closure 

t  sup  * 

t  sup  ** 

t' 

domain  restriction 

p  ->    t 

p  ->    t 

P  -   t 

range  restriction 

t  <  -  p 

t  <  -  p 

t  -   p 

restriction 

t  restr  p 

t  restr  p 

t   I  P 

sequence  filtering 

(added) 

p  xi  t 

P  ^t 
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TABLE  3.    Nonprimitive  Extensional  Ojjerations:    Gro.up  2 


Name 

Old  Input  Form 

New  Input  Form 

Publication  Form 

first  member 

alpha  t 

alpha  t 

a  t 

last  member 

omega  t 

omega  t 

ijj  t 

initial  sequence 

ALPHA  t 

ALPHA  t 

A  t 

final  sequence 

OMEGA  t 

OMEGA  t 

n  t 

ordered  union 

t  ;  u 

t  ;  u 

t  ■  u 

cons  left 

x  cl  t 

X  cl  t 

X  cl  t 

cons  right 

t  cr  X 

t  cr  X 

t  cr  X 

minimum 

min  s 

min  s 

min  8 

maximum 

max  s 

max  s 

max  s 

intersection 

s  cap  t 

s  cap  t 

s  n   t 

set  difference 

s\t         . 

s\t 

s    \  t 

apply  functional  record 

t  @    hat  X 

t  @  hat  x 

t  @I 

apply  functional  structure 

t  !  X 

t!  X 

t  !  z 

minimize 

mu  t 

mu  t 

M  t 

database  index 

index  x  d 

X  index  d 

X  index  d 

database  select 

select  X 

X  select  d 

X  select  d 

database  join 

join  X 

X  join  dblist 

X  join  dblist 

array  to  sequence 

as  t 

as  t 

as  t 

sequence  to  array 

sa  t 

t  sa  i 

t  sa  i 

seq.  to  zero-origin  array 

saO  t 

(deleted) 

(deleted) 

relative  product 

rp  f  t 

trp  f 

t  1  / 

relative  product  inverse 

rpi  f  t 

f  rpi  t 

/   1  t 

array  concatenation 

t  cat  u 

t  cat  u 

t  cat  u 

relation  sort 

rsort  s 

rsort  s 

rsort  a 

sort 

sort  s 

sort  s 

sort  s 

unit  image 

unimg  t  X 

t  unimg  X 

t  unimg  I 

all 

all  t 

all  t 

all  t 

sequence  to  matrix 

ssm  t 

ssm  t 

ssm  t 

TABLE  4.    Primitive  Intensional  Operations 


Name 

Old  Input  Form 

New  Input  Form 

Publication  Form 

application 

f  @     X 

f  @   x 

f    @      X 

image 

img  f  s 

f  img  s 

f  img  s 

composition 

f     g 

fog 

f    '9 

infix  to  prefix 

(added) 

(op  +  ),  (op  times),  ... 

\+\,  |xl.    ■  •  • 

left  section 

(x+),  (x-),... 

(Isec  x  +  ),  ... 

l^+Mx-1,  •■• 

right  section 

(+y),(-y)>- 

(rsec  +    y),  ... 

l+yM-yl>  ■■■ 

paralleling 

fllg 

f||g 

/  II? 

isomorphism 

f  $  t 

f  $  t 

/  $  t 

formal  application 

f  @    bar  g 

(deleted) 

(deleted) 

functional  condition 

(p->  f;  g) 

(ifp->  f ;  g) 

(P  ^  /;  g) 

curry 

curry  f 

curry  f 

curry  / 

uncurry 

uncurry  f 

uncurry  f 

uncurry  / 

filtering 

PHI  p  (d,  r) 

pPHI  S 

p  ^  S 

iteration 

iter  [p  ->    f] 

(iter  p  ->    f) 

iter  [p  -»   /] 

formalization 

+    bar,  times  bar,  ... 

(+    bar),  (times  bar),  ... 

T,  X 

identity 

Id 

I 

I 
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TABLE  5.    Nonprimitive  Intensional  Operations 


Name 

Old  Input  Form 

New  Input  Form 

Publication  Form 

while  loop 

while  [p,  f] 

(f  while  p) 

/  while  p 

array  reduction 

f  red  i 

f  red  x 

f    §    X 

repeated  composition 

f  sup  n 

f  sup  n 

/" 

value  of  node 

upsilon  f 

upsilon  f 

V  f 

operate  on  form 

phif 

phif 

<t>  f 

operate  on  data 

delta  f 

delta  f 

6  f 

image  of  structure 

PIf 

PIf 

n/ 

extension 

extend  (t,  f) 

t  extend  f 

t  extend  / 

restriction 

restrict  (s,  f) 

s  restrict  f 

s  restrict  / 

formal  negation 

wig  p 

wig  p 

~P 

TABLE  6.    Miscellaneous  Operations 


Name 

Old  Input  Form 

New  Input  Form 

Publication 

Form 

sum 

X  +   y    • 

X  +   y 

X  +  y 

difference 

X  -  y 

X  -  y 

I  -  y 

product 

X  times  y 

X  times  y 

X    X  y 

quotient 

X  divide  y 

X  divide  y 

X  ^  y 

inequality 

X  !=   y 

X  !=  y 

X   ^    y 

less 

X  <    y 

X  <   y 

X  <    y 

greater 

X  >    y 

X  >   y 

X  >    y 

less  or  equal 

X  <  =   y 

X  <  =   y 

X  ^    y 

greater  or  equal 

X  >  =   y 

X  >  =   y     '' 

X  ^    y 

conjunction 

X  andsign  y 

X  andsign  y 

X  Ay 

disjunction 

X  orsign  y 

X  orsign  y 

X  My 

negation 

not  X 

not  X 

-iX 

cartesian  product 

s  cart  t 

s  cart  t 

s    X    t 

TABLE  7.    Data  Input  Operations  and  Syntax 


Name 

Input  Form 

Publication  Form 

identifiers 

a,  b',  total,  etc. 

a  ,  6  ',  total,  etc. 

strings 

"abed" 

"abed" 

booleans 

true,  false 

true,  false 

relation 

(rel(x:y),  ...  ) 

((x  y),    ■■■   ) 

set 

(set  x  y  ...  ) 

{x,  y,      •  •    } 

sequence 

(seq  X  y  ...  ) 

(x,  y,    ■         ) 

list 

(list  X  y  ...  ) 

<  X,   y,           •    > 

subrange  set 

(setrange  m  to  n) 

{m,  . . . ,n} 

subrange  sequence 

(seqrange  m  to  n) 

(m,  .  .  .  ,n) 

subrange  list 

(listrange  m  to  n) 

<  m , .  . . ,n> 
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TABLE  8.    RPL  Command  Types 


Name 

Input  Form 

Publication  Form 

data  definition 

X  =  =   y 

X  =    y 

prefix  function  definition 

f  X  =  =   y 

f  x=    y 

infix  function  definition 

X  f  y  =  =   z 

X  f  y  =    z 

write  data  to  a  file 

file  "name"  =  =   x 

file  "name "  =    x 

read  data  from  a  file 

X  ^=    (file  "name") 

X  =    file  "name " 

output,  form  1 

display  x 

display  x 

output,  form  2 

dis  X 

display  z 

output,  form  3 

dx 

dz 

output,  form  4 

X 

X 

output  value  of  definition 

val  X 

val  X 

output  function  environment 

env  f 

env  / 

output  entire  environment 

env 

env 

168 


I 


APPENDIX  F  -  RPL  CODE  AND  DOCUMENTATION 


(RPL 

************************************************************ 
calls:       INIT_SYS_NAMES,  WRITE,  MAPCAR ,  SET_USER_ENV , 

TERPRI,  PRINl,  SPACES,  CONS,  READCMD ,  EXECUTE 
uses  free:  BUILT_IN_PREFIX_OPS ,  INTOPS,  SYSOPS,  CMD, 

USERDEFS,  SYSTEM_ENV,  PREFI X_OPNAMES ,  OPNAMES , 
TEMPNAMES,  ERRORCODE ,  E,  FILTER_ON 
comments:   Shell  -For  RPL  Interpreter, 
************************************************************ 

-C LAMBDA  NIL 
(PROG  NIL 

(INIT_SYS_NAMES) 
(SETD  FILTER_ON  NIL) 

(WRITE  (QUOTE  (Loading  RPL >)) 

(SETQ  E  SYSOPS) 

(SETQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(SETQ  TEMPNAMES  OPNAMES) 
(SETQ  OPNAMES  NIL) 

(MAPCAR  INTOPS  (QUOTE  EXECUTE) ) 
(SETQ  OPNAMES  TEMPNAMES) 
(SETQ  PREFIX_OPNAMES 
BUILT_IN_PREFIX_OPS) 
(SETQ  E  (CONS  (CONS  (QUOTE  SYSTEM) 

(QUOTE  SYSTEM) )  E) ) 
(SETQ  SYSTEM_EN'v  E) 
(SETQ  USERDEFS  NIL) 
(SET_USER_ENV) 
(TERPRI) 
( TERPR I ) 

(WRITE  (QUOTE  (RPL  INTERPRETER  ON  LINE!!))) 
(TERPRI) 
(TERPRI) 
LOOP (SETQ  ERRORCODE  (QUOTE  ERRORFREE)) 
(PRINl  (QUOTE  ?::  )  ) 
(SPACES  1) 

(SETQ  CMD  (READCMD)) 
(TERPRI) 
(EXECUTE  CMD) 
(GO  LOOPD) 
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(INIT_SYS_NAMES 

************************************************************ 
called  by:  RPL 
uses  -free:  EMSG,  SETOP,  NUMOP,  SPECI  AL_CASES ,  SETS, 

INTOPS,  BIFTAG_INFIX,  SYSOPS ,  PREFI X_OPNAMES , 
BUILT_IN_PREFIX_OPS,  OPNAMES,  USERDEFS 
comments:   Initialization  required  to  execute  RPL. 
************************************************************ 
C LAMBDA  NIL 

(SETQ  USERDEFS  NIL) 
(SETQ  OPNAMES 

(QUOTE  (SYSTEM  done  -file  display  dis  val  env  sup  rel 
set  seq  list  setrange  seqrange  li strange  func 
empty  true  false  -filter  hd  tl  1  sec  rsec  op  if 
iter  or  and  <>  #  @  o  $  red  img  curry  uncurry 
PHI  I  while  upsilon  phi  delta  PI  sel  %1  ,  : 
extend  restrict  wig  cup  member  nomem  i subset 
subset  =  ->  <—  restr  ;  cl  cr  cap  \  @hat  f  cat 
+    -    times  divide  /  !=  <  >  <=  >=  andsign  or sign 
cart  un  cur  unc  theta  epsilon  size  DELTA  cnv 
rev  dom  rng  mem  Lm  Rm  Mm  run  lun  bun  init  term 
alpha  omega  ALPHA  OMEGA  min  max  uset  mu  index 
select  join  as  sa  rp  rpi  rsort  sort  unimg  all 
ssm  not  PHIaux  xi  > ) ) 
(SETQ  BUILT_IN_PREFIX_OPS 

(QUOTE  (Isec  rsec  op  if  iter  hd  tl  un  cur  unc  size 
theta  epsilon  DELTA  cnv  rev  dom  rng  mem  run 
lun  bun  init  term  alpha  omega  ALPHA  OMEGA  min 
max  mu  select  join  as  sa  rsort  sort  all  ssm 
curry  uncurry  I  while  upsilon  phi  delta  PI 
wig  not  uset) ) ) 
(SETQ  PREFI X_OPNAMES  NIL) 

CSETQ  SYSOPS  (QUOTE  ((unimg  closure  5elect_all) 

(hd  closure  Hd ) 
(tl  closure  Tl ) 
(filter  closure  filter) 
(run  c 1 osur e  r un ) 
(#  closure  construction) 
(size  closure  cardinality) 
(rpi  closure  rel _prod_inv) 
(rp  closure  rel_prod) 
(img  closure  img) 
(empty  Eset) 
(true  true) 
(false  false) 
(-•-  closure  +) 
(—  closure  -) 
(times  closure  *) 
(divide  closure  /) 
(/  closure  /) 
(<  closure  <) 
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>  closure  >) 

<=  closure  <=) 

>=  closure  >=) 

not  closure  not) 

or  closure  or) 

and  closure  and) 

orsign  closure  or) 

andsign  closure  and) 

epsilon  closure  el ementselect) 

theta  closure  uni tset_5elect ) 

un  closure  unitset) 

cup  closure  union) 

cap  closure  intersection) 

\  closure  setdi-f-f) 

cart  closure  cart) 

subset  closure  subset) 

! subset  closure  ! subset) 

=  closure  =) 

!=  closure  <>) 

<>  closure  <>) 

member  closure  member) 

nomem  closure  nomem) 

•/.  I  closure  '/.\  ) 

-file  closure  -file) 

sel  closure  sel ) 

:  closure  : ) 

dom  closure  dom) 

rng  closure  rng) 

cnv  closure  converse) 

sup  closure  superscript) 

rev  closure  reverse_array ) 

**  closure  star) 

i-    closure  isomorphism) 

as  closure  array_to_seq) 

sa  closure  seq_to_array) 

min  closure  min) 

max  closure  max) 

cat  closure  concatenation) 

cur  closure  curry_ext) 

unc  closure  uncurry_e>;t ) 

rsort  closure  rsort) 

sort  closure  sort) 

red  closure  reduction) 

uset  closure  unique_set] 


(SETQ  E!IFTAG_INFIX 
(QUOTE  (+  -  *  / 
setdif-f 


<=  >=  or  and  union  intersection 
cart  subset  ! subset  =  <>  member  nomem 
construction  '/.\     sel  :  i  mg  rel_prod  rel_prod_in' 
■Filter  superscript  isomorphism  concatenation 
seq_to_array  select_all  reduction))) 
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(term 

t 

( K    Mm 

t 

(init 

t 

(t    <- 

P 

(p    -> 

t 

CSETQ  INTOPS  (QUOTE  (Co  ==(-Func  (-F  g)  (-func  x  (-f  (g  x] 

dun  t  ==((run  o  cnv)  t)) 
(bun  t  ==((run  t)  and  dun  t))) 
(k  Rm  t  ==(;<  member  (rng  t)  )  ) 
(x  Lm  t  ==(x  member  (dom  t))) 
(mem  t  ==((dom  t)  cup  (rng  t))) 
==( (rng  t)  \  (dom  t) ) ) 
==(x  member  (mem  t))) 
==( (dom  t)  \  (rng  t) ) ) 
==(  (p  o  tl  )  -filter  t)  ) 
==(  (p  o  hd)  -filter  t)  ) 
(t  restr  p  ==((p  ->  t)  <-  p)) 
(t  ;  u  ==(t  cup  ( (rsec  member 

((dom  u)  \  (dom  t)))  ->  u) ) ) 
(alpha  t  ==((theta  o  init)  t)) 
(omega  t  ==((theta  o  term)  t)) 
C ALPHA  s  ==(5  <-(rsec  nomem  (term  sH 
(OMEGA  t  ==((r5ec  nomem  (init  t)) 

->  t)  ) 
(X  cl  t  ==((rel  (X  : (alpha  t))) 

cup  t) ) 
Ct  cr    X  ==(t  cup  (rel  ((omega  t) :  xU 
(-f  e  X  ==(-f  x)  ) 
( X  ,  y  == ( 1 i  st  X  y ) ) 
C7.  !■/.!  ==(-func  (f  g)  (-func  (x  y) 

(list  (-f  X)  (g  y] 
(I  X  ==  x) 
(wig  p  ==(not  op)) 
(DELTA  X  ==(li5t  K  x) ) 
(phi  ==(l5ec  I  •/.  17. :  )  ) 
(delta  ==(r5ec  "/.  I  7. 1  I)) 
(f  while  p  ==(i-f  p  —  >  (iter  p  ->  -f ) 

;  I>> 
(PI  -f  ==(delta  fr^sc    rp  f))) 
(upsilon  -f  == 

(sel  o  (I  '/.\y.\     -f )  )  ) 
(t  extend  -f  == 

(if  (rsec  member  (dom  t)) 
->  (Isec  t  sel)  ;  -f )  ) 
(s  restrict  -f  ==(((op  :) 

D  (  (I  7. 1  7. !  -f  )  o  DELTA )  )  i  mg  s )  ) 
(x  index  t  ==(((r5ec  sel  x) 

( :  bar )  I )  i  mg  t ) ) 
(t  @hat  X  == 

( (hd  (:  bar)  ((rsec  @  x)  o  tl)) 
img  t ) ) 
(t  !  X  ==( (rsec  @  x)  *  t) ) 
Cmu  t  ==(t  \  (t  7.:  (t  sup  +1 
(p  xi  r  ==(mu  ( (r  sup  +)  restr  p))) 
Ct  PHIaux  5  ==((5  sel  1)  , 

((rsec  Lm  t)  xi  (s  sel  21 
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(p  PHI  5  ==(((s  sel  1)  <-  p) 

PHIauK  s)) 
(ssm  t  ==((unc  o  (rsec  sa  1)) 

(  (rsec  sa  1)  $■    t)  )  ) 
(y  all  t  ==((cnv  t)  unimg  y) ) 
C;<  select  d  == 

(rng  o  (rsec  ->  (k  indeK  d  II 
(;<  join  dp  == 

(Cdsec  (cup  o  (hd  (,  bar)  tl  )  )  img) 
o  ( ( (rsec  sel  1 ) 

(•/. !  bar)  (rsec  sel  2)  ) 
o  (  (cnv  ■/.  r/. !  I) 
o  ( ( 1  sec  K  index) 

■/.!■/.!  (Isec  K  index: 
dp)  ) 
C curry  f  ==(-func  x  (-Func  y  (-f  (x  ,  yl 
(uncurry  -f  ==(-func  (x  y)   (  (f  x)  yl! 
(SETQ  SETS  (QUOTE  (rel  set  setrange  seq  seqrange  list 

1 i  strange) ) ) 
(SETQ  SPECIAL_CASES 

(QUOTE  (Eset  Erel  rel  set  setrange  seq  seqrange  list 
li  strange  op  Isec  rsec  func  i -f  when  iter 
repeat  reduce) ) ) 
(SETQ  NUMOP  (QUOTE  (+-*/<  >  <=  >=) ) ) 
(SETQ  SETOP  (QUOTE  (cart  union  intersection  setdi-f-f 

subset  Isubset))) 
(SETQ  EMSG  (QUOTE  ( (BAD_CMD  bad  command) 

(UBI  unbound  individual) 

(PARAM  number  o-F  parameters  in  error) 

(BAD_RANGE  bad  range  variables) 

(BAD_SEQ  bad  sequence) 

(EXP_SET  set,  relation,  sequence 

or  list  expected) 
(EXP_SEQ  sequence  expected) 
(EXP_NUM  numeric  arguments  expected) 
(EXP_REL  relation  expected) 
(UBTE  unbound  table  element) 
(EXP_FUNC  -Function  expected) 
(UDF  unde-fined  -Function) 
(BAD_SYNTAX  syntax  error) 
(EXP_BOOL  boolean  predicate  expected) 
(BAD_ARGS  invalid  arguiTients) 
(EXPJJNITSET  unit  set  expected) 
(EXP_INFIX  infix  operator  expected) 
(EXP_PAIR  elementary  pair  expected) 
(EXP_NSET  numeric  set  expected) 
(EXP_ARRAY  Sir r Ay    expected) 
(ZERO_DIV  zero  divisor) 
(EXP_NEliPTY  non-empty  set  expected) 
(BIF  built  in  function  or  RPL  keyword!) 
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(SET_USER_ENV 

************************************************************ 
calls:      MEMBER,  WRITE,  TERPRI,  READ_USER_DEFS ,  READTERM 
called  by:  RPL,  EXIT 
binds:      RESP ,  FILENAME 
************************************************************ 
[LAMBDA  NIL 

(PROG  (RESP  FILENAME) 

(WRITE  (QUOTE  (DO  YOU  WANT  TO  RESUME  A  PREVIOUS 

RPL  SESSION?  <y/n>?))) 
(SETQ  RESP  (READTERM) ) 
(COND 
((MEMBER  RESP  (QUOTE  (y  Y) ) ) 

(WRITE  (QUOTE  (INPUT  FILENAME))) 

(TERPRI) 

(SETQ  FILENAME  (READTERM) ) 

( READ_USER_DEFS  F I LENAME 1 ) 

(EXECUTE 

************************************************************ 
ar gs:       CMD 
calls:      MEMBER,  POSIT,  LENGTH,  DEF_BINDIN6,  FILE_WRITE, 

EV,  DISPLAY,  EXIT,  LIST,  CONS,  ERROR_HANDLER 
called  by:  READ_USER_DEFS,  RPL 
binds:      X 
uses  -free:  E 

ccmments:   Command  level  parser. 
************************************************************ 
[LAMBDA  (CMD) 
(PROG  (X) 

(SETQ  X  (POSIT  CMD  (QUOTE  ==) ) ) 
(RETURN  (COND 

( (AND  (EQ  X  2) 

(EQ  (LENGTH  CMD)  3) ) 
(DEF_BINDING  CMD) ) 
C (AND  (EQ  X  3) 

(EQ  (LENGTH  CMD)  4) ) 
(COND 

(  (EQ  (CAR  CMD)   (QUOTE  -file)) 
(FILE_ WRITE  (EV  (CADR  CMD)  E) 
(EV  (CADDDR  CMD)  E) ) ) 
(T  (DEF_BINDING  CMDl 
( (AND  (EQ  X  4) 

(EQ  (LENGTH  CMD)  5) ) 
(DEF_BINDING  CMD) ) 
C ( EQ  X  0 ) 
(COND 

( (AND  (MEMBER  (CAR  CMD) 

(QUOTE  (display  dis  d  env  val ) ) ) 
(EQ  (LENGTH  CMD)  2) ) 
(DISPLAY  CMD) ) 
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((EQ  (CAR  CMD)   (QUOTE  done))  (EXIT)) 
C (EQ  (LENGTH  CMD)  1) 
(COND 

((EQ  (CAR  CMD)  (QUOTE  env) ) 

(DISPLAY  (LIST  (QUOTE  snv)  NIL))) 
(T  (DISPLAY  (CONS  (QUOTE  d)  CMD: 
(T  (ERROR_HANDLER  (QUOTE  BAD_CMD)  CMD: 
(T  (ERROR_HANDLER  (QUOTE  BAD_CMD)  CMDD) 

(DEF_BINDING 

args:       DEXP 

calls:      MEMB,  ERROR_HANDLER ,  LDIFFERENCE,  SPACES, 

WRITE,  LENGTH,  LOOKUP,  CONS,  LIST,  EV ,  LAST, 
SASSOC,  TERPRI,  RPLACD ,  READTERM 
called  by:  EXECUTE 

binds:      NAME,  NEWNAME,  EXP,  RESP 

uses  -Free:  ERRORCODE,  OPNAMES ,  USERDEFS ,  PREFIX_OPNAMES ,  E 
comments:   Makes  all  bindings  to  the  environment;  includes 
mechanism  to  implement  simple  recursion. 
************************************************************ 
CLAMBDA  (DEXP) 

(PROG  (NAME  EXP  NEWNAME  RESP) 
CCOND 
( (EQ  (LENGTH  DEXP)  5)  (SETQ  NAME  (CADR  DEXP) ) ) 
(T  (SETQ  NAME  (CAR  DEXP: 
CCOND 
((MEMB  NAME  OPNAMES) 

(WRITE  (QUOTE  (SYSTEM  DEFINED  FUNCTION  OR 

KEYWORD ,  0 VER WR I TE?  <  y / n  > ) ) ) 
(SETQ  RESP  (READTERM))   (TERPRI) 
(COND 
(CNOT  (MEMB  RESP  (QUOTE  (Y  yl 

(WRITE  (QUOTE  (ABORT  AT  USER'S  REQUEST))) 
(TERPRI)   (TERPRI)   (GO  EXIT: 
CCOND 
( (EQ  (LOOKUP  NAME  E)  NIL) 
(SETQ  NEWNAME  NIL) 

( SETQ  E  ( CONS  ( CONS  NAME  NIL)  E ) ) ) 
(T  (SETQ  NEWNAME  T: 
CCOND 
((EQ  (LENGTH  DEXP)  4) 

(SETQ  EXP  (LIST  (QUOTE  closure) 

(CADR  DEXP) 
(CADDDR  DEXP)  E) ) ) 
( (EQ  (LENGTH  DEXP)  5) 

(SETQ  EXP  (LIST  (QUOTE  closure) 

(LIST  (CAR  DEXP) 

(CADDR  DEXP) ) 
(CADDDR  (CDR  DEXP) )  E) ) ) 
(T  (SETQ  EXP  (EV  (CAR  (LAST  DEXP))  E: 
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BIND_NAME 
(RETURN  (COND 

C (EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

( (EQ  NEWNAME  T) 
CCOND 

((AND  (MEMB  NAME  PREFIX_OPNAMES) 
(EQ  (LENGTH  DEXP)  5) ) 
(LDIFFERENCE  PREFIX_OPNAMES 
(LIST  NAME) ) ) 
((AND  (NOT  (MEMB  NAME  PREFI X_OPNAMES) ) 
(NOT  (EQ  (LENGTH  DEXP)  5))) 
(SETQ  PREFI X_OPNAMES 

(CONS  NAME  PREFIX_OPNAMES: 
(COND 
((NOT  (MEMB  NAME  OPNAMES) ) 

(RPLACD  (SASSOC  NAME  E)  EXP) 
(RPLACD  (SASSOC  NAME  USERDEFS)  DEXP) 
(SPACES  1) 

(WRITE  (LIST  NAME  (QUOTE  Rede-fined))) 
(TERPRI)  (TERPRD) 
(T  (SETQ  USERDEFS 

(CONS  (CONS  NAME  DEXP)  USERDEFS) ) 
CCOND 

((AND  (LISTP  EXP)   (EQ  (CAR  EXP) 
(QUOTE  closure) ) ) 
(COND 

( (OR  (EQ  (LENGTH  DEXP)  4) 
(EQ  (LENGTH  DEXP)  3) ) 
(SETQ  PREFIX_OPNAMES 

(CONS  NAME  PREFI X_OPNAMES: 
(RPLACD  (SASSOC  NAME  E)  EXPj 
(T  (WRITE  (QUOTE  (BINDING  CANNOT  BE  MADE))) 
(TERPRI)   (TERPRI) 
( COND 

((NOT  (EQ  NEWNAME  T) )   (SETQ  E  (CDR  E: 
EXITj) 


\U  i  or  !_!-!> 

CMD 

MEMBER ,  L I T ATOM ,  PR I NT ,  SHOW_ATOM ,  TERPR I , 

DISPLAY_ENV,  ERROR_HANDLER ,  LOOKUP,  EV ,  TYPE, 

LENGTH 

EXECUTE 

KEY,  EXP,  EVEXP 

ERRORCGDE,  E,  USERDEFS 

Performs  all  output  to  the  screen  to  include 

the  "val"  and  "env"  commands. 


I 


args: 

cal Is: 

called 

by 

bindsi 

uses  f 

ree 

commen 

ts: 
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i:  LAMBDA  (CMD) 

(PROG  (KEY  EXP  EVEXP) 

(3ETQ  KEY  (CAR  CMD) ) 
(SETQ  EXP  (CADR  CMD)) 
CCOND 
[(MEMBER  KEY  (QUOTE  (d  dis  display))) 
(COhJD 

C (LITATOM  EXP) 

(SETQ  EVEXP  (LOOKUP  EXP  USERDEFS) ) 
(COND 

( (NULL  EVEXP) 

(PRINT  (QUOTE  Undefined)))   ' 
(T  (PRINT  EVEXP : 
(T  (SETQ  EVEXP  (EV  EXP  E) ) 
(COND 

( (NULL  EVEXP) 

(PRINT  (QUOTE  Undefined))) 
(T  (SHOW_ATOM  EVEXP) 
(TERPRI3 
(T  CCOND 

( (NOT  (NULL  EXP) ) 

(SETQ  EVEXP  (EV  EXP  El 
( COND 

( (EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

C(AND.  (EQ  KEY  (QUOTE  val) ) 
(LITATOM  (CADR  CMD))) 
(COND 

( (NULL  EVEXP) 

(PRINT  (QUOTE  Undefined)) 
(T  (SHOW_ATOM  EVEXP) 
(TERPRi: 
((AND  (EQ  KEY  (QUOTE  env)) 
(NULL  EXP) ) 
(DISPLAY_ENV  EXP) ) 
((AND  (EQ  KEY  (QUOTE  env)) 
(LITATOM  (CADR  CMD)) 
(EQ  (TYPE  EVEXP) 

(QUOTE  closure) ) 
(EQ  (LENGTH  EVEXP)  4) ) 
(DISPLAY_ENV  EXP) ) 
( (EQ  KEY  (QUOTE  env)) 
(ERROR_HANDLER 

(QUOTE  EXP_FUNC)  CMD) ) 
(T  (ERROR_HANDLER 

(QUOTE  BAD_SYNTAX)  CMDD 
(TERPRI]) 
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(ERROR_HANDLER 
************************************************************** 

args:       CODE,  EXP 

calls:      WRITE,  TERPRI ,  PRINT_LIST,  LOOKUP 

called  by:  DEF_BINDING,  DISPLAY,  EVRANGE,  EVSEQ,  RP APPLY, 
ARRAY_REDUCTION,  MIN_SET,  RPL_REPEAT ,  EXECUTE, 
EV,  EV_SPECIAL_CASES,  INFIXOP,  PREFIXOP, 
BIF_APPLY,  ARRAY_CONCATENATION,  HEAD,  MAX_SET, 
MEM,  SEL,  SUPERSCRIPT,  TAIL,  BINARY_LI3T, 
COERCE_TO_REL 

uses  -free:  EMSG,  FILTER_ON,  ERRORCODE 

comments:   Based  on  the  CODE  given,  displays  the  appro- 
pi  ate  error  message  and  the  probable  cause  of 
error,  EXP. 

tLAMBDA  (CODE  EXP) 
(PROG  NIL 

(COND 
( (EQ  FILTER_ON  T) 
(GO  EXIT) ) ) 
(IMRITE  (QUOTE  (***  ERROR  *-»■*))) 
(WRITE  (LOOKUP  CODE  EMSG) ) 
(TERPRI) 

(WRITE  (OUOTE  (Cause  o-f  error  ==>))) 
(PRINT_LIST  EXP) 
(TERPRI) 
EXIT(SETQ  ERRORCODE  CODE)  NIL 3) 

(EXIT  f 

calls:      MEMBER,  WRITE,  TERPRI,  WRITE_USER_DEFS , 

READTERM,  SET_USER_ENV  ■ 

called  by:  EXECUTE 

uses  -free:  BUILT_IN_PREFIX_OPS,  SYSTEM_ENV ,  USERDEFS , 
PREFIX_OPNAMES,  E,  FILENAME,  RE3P 

comments:   Used  to  exit  the  RPL  environment  or  begin 
another  session. 

L LAMBDA  NIL 

(WRITE  (QUOTE  (DO  YOU  WANT  TO  SAVE  ENVIRONMENT  FOR 

FUTURE  USE?  <y/n?>) ) ) 
(SETQ  RESP  (READTERM)) 
( COND 

((MEMBER  RESP  (QUOTE  (y  Y))) 
(WRITE  (QUOTE  (INPUT  FILENAME))) 
( TERPR I ) 

(SETQ  FILENAME  (READTERM)) 
(WRITE_USER_DEFS  FILENAME))) 
(TERPRI) 
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(WRITE  (QUOTE  (EXIT  TO  LISP  -  PRESS  -^D)  )  ) 

(TERPRI) 

(WRITE  (QUOTE  (EXIT  TO  UNIX  -  PRESS  -C) ) ) 

(TERPRI) 

(WRITE  (QUOTE  (CONTINUE  RPL  -  PRESS  <RETURN>) ) 

(TERPRI) 

(READTERM) 

(TERPRI) 

(WRITE  (QUOTE  (DO  YOU  WANT  TO  CLEAR  CURRENT 

ENVIRONMENT?  <y/n?>))) 
(SETQ  RESP  (READTERM)) 
(TERPRI) 
(COND 

((MEMBER  RESP  (QUOTE  (y  Y) ) ) 

(SETQ  E  SYSTEM_ENV) 

(SETQ  USERDEFS  NIL) 

(SETQ  PREFIX_OPNAMES  BUILT_IN_PREFI X_OPS) ) ) 
(SET  USER  ENVl) 


(EV 

args:        EXP,  E 

calls:      NUMBERP,  STRINGP,  ATOM,  MEMBER,  LOOKUP, 

ERROR_HANDLER,  EV_SPECI AL_CASES ,  LENGTH, 

PREFIX OP,  INF IX OP 
called  by:  EXECUTE,  DEF_BINDING,  DISPLAY,  MAPEV , 

ev_special_cases,  evseq,  infixop,  prefixop, 
rp apply,  array_reduction,  rpl_repeat , 
mak:e_unique 

binds:       X,  TAG 
uses  -free:  SPECI AL_CASES 

comments:   Given  an  expression,  EXP,  and  its  environment, 
E,  this  function  directs  its  evaluation. 

C LAMBDA  (EXP  E) 
(PROG  (X  TAG) 

( RETURN  ( COND 

( (NUMBERP  EXP)  EXP) 
( (STRINGP  EXP)  EXP) 
( (ATOM  EXP) 

(SETQ  X  (L00K:UP  EXP  E)  ) 
(COND 

( (EQ  X  NIL) 

(ERROR_HANDLER 

(QUOTE  UBI)  EXP) ) 
( T  X  )  )  ) 
(T  (SETQ  TAG  (CAR  EXP)) 
(COND 

( (MEMBER  TAG  SPECI AL_CASES) 
(EV  SPECIAL  CASES  EXP  E) ) 
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( (EQ  (LENGTH  EXP)  2) 

(PREFIXOP  EXP  E) ) 
C (EQ  (LENGTH  EXP)  3) 
(COND 

( (LISTP  (CADR  EXP) ) 

(EV_SPECIAL_CASES  EXP  E) ) 
(T  (INFIXOP  EXP  E: 
(T  (ERROR_HANDLER 

(QUOTE  PAR AM)  EXFl) 

( EV_SPEC I AL_C ASES 

************************************************************ 
args:       EXP,  E 

calls:      MEMBER,  ALL_PAIRS,  ATOM,  CONS,  MAKE_UNIQUE, 
ERROR_HANDLER ,  LENGTH,  EV ,  EVRANGE ,  EVSEQ , 
LIST,  TYPE,  RPL_REPEAT,  ARRAY_REDUCTION 
called  by:  EV 

binds:      TAG,  LOW,  HIGH,  F 

uses  -free:  PREFIX_OPNAMES ,  ERRORCODE ,  SETS 
comments:   Handles  all  operators  with  special  syntax. 
************************************************************ 
: LAMBDA  (EXP  E) 

(PROG  (TAG  LOW  HIGH  F) 

(SETQ  TAG  (CAR  EXP) ) 
( RETURN  ( COND 

Z (MEMBER  TAG  SETS) 
(COND 

C (EQ  TAG  (QUOTE  set) ) 

(SETQ  EXP  (CONS  (QUOTE  Eset) 

( MAKE_UN I QUE 
(CDR  EXP) 

NIL  e: 

( (EQ  TAG  (QUOTE  rel ) ) 

(SETQ  EXP  (CONS  (QUOTE  Erel ) 

(MAKE_UNIQUE 
(CDR  EXP) 
NIL  E) ) ) 
(COND 

( (NOT  (ALL_PAIRS  (CDR  EXP) ) ) 
(ERROR_HANDLER 

(QUOTE  EXP_REL)  EXP) ) 
(T  EXP) ) ) 
C(EQ  TAG  (QUOTE  setrange) ) 
(COND 

C (AND  (EQ  (LENGTH  EXP)  4) 
(EQ  (CADDR  EXP) 
(QUOTE  to) ) ) 
(SETQ  LOW  (EV  (CADR  EXP)  E) ) 
(SETQ  HIGH  (EV  (CADDDR  EXP)  E)) 
(COND 
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C (EQ  ERRORCODE 

(QUOTE  ERROR-FREE)  ) 
(SETQ  EXP 

(CONS  (QUOTE  Eset) 

(EVRANGE  LOW  HIGH: 
(T  (QUOTE  impassible: 
(T  (ERROR_HANDLER 

(QUOTE  BAD_RANGE)  EXPD 
[(MEMBER  TAG  (QUOTE  (seq  seqrang-s)  )  ) 
(SETQ  EXP  (CONS  (QUOTE  Erel ) 

(EVSEQ  EXP  E: 
[(MEMBER  TAG  (QUOTE  (list  listrange))) 
(SETQ  EXP  (CONS  (QUOTE  Erel) 

(EVSEQ  EXP  E: 
(T  (QUOTE  impossible: 
((MEMBER  TAG  (QUOTE  (Eset  Erel)))  EXP) 
(  (EQ  TAG  (QUOTE  -func)) 
(LIST  (QUOTE  closure) 
(CADR  EXP) 
(CADDR  EXP)  E) ) 
[(AND  (EQ  TAG  (QUOTE  op)) 
(EQ  (LENGTH  EXP)  2) ) 
(SETQ  F  (EV  (CADR  EXP)  E) ) 


(COND 

([OR  (NOT 

(EQ  (TYPE  F) 

(QUOTE  closure) ) ) 

(AND 

(EQ  (LENGTH  F)  2) 
(MEMBER  (CADR  EXP) 

PREFIX  OPNAMES) ) 

(AND 

(EQ  (LENGTH  F)  4) 
(ATOM  (CADR  F: 

(ERROR_l 

HANDLER 

(QUOTE  EXP  INFIX) 

(CADR 

EXP) ) ) 

(T  (LIST 

(QUOTE  closure) 
(QUOTE  ?;<) 

(LIST  (LIST  (QUOTE 

?;<) 

( QUOTE 

sel  )  1 

(CADR  EXP) 

(LIST  (QUOTE 

?k) 

(QUOTE 

sel  )  2 

1) 


e: 

((AND  (EQ  TAG  (QUOTE  1  sec ) ) 
(EQ  (LENGTH  EXP)  3) ) 
(LIST  (QUOTE  closure) 
(QUOTE  ?;<) 
(LIST  (CADR  EXP) 
(CADDR  EXP) 
(QUOTE  ?x) )  E) ) 
((AND  (EQ  TAG  (QUOTE  rsec)) 
(EQ  (LENGTH  EXP)  3) ) 
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(LIST  (QUOTE  closure) 
(QUOTE  ?;<) 
(LIST  (QUOTE  ?K) 
(CADR  EXP) 
(CADDR  EXP) )  E) ) 
((AND  (EQ  TAG  (QUOTE  i -f )  ) 
(EQ  (LENGTH  EXP)  6) 
(EQ  (CADDR  EXP)  (QUOTE  ->) ) 
(EQ  (CADDDR  (CDR  EXP) )  (QUOTE  ; ) ) ) 
(LIST  (QUOTE  closure) 
(QUOTE  ?x) 
(LIST  (QUOTE  when) 

(LIST  (CADR  EXP) 

(QUOTE  ?x) ) 
(QUOTE  do) 
(LIST  (CADDDR  EXP) 

(QUOTE  ?>;)  ) 
(QUOTE  elsedo) 
(LIST  (CADDDR  (CDDR  EXP)) 
(QUOTE  ?K) ) )  E) ) 
C (EQ  TAG  (QUOTE  when)) 
(COND 

( (EQ  (EV  (CADR  EXP)  E) 
(QUOTE  true) ) 
(EV  (CADDDR  EXP)  E) ) 
(  (EQ  (EV  (CADR  EXP)  E) 
(QUOTE  -false)  ) 
(EV  (CADDDR  (CDDR  EXP) )  E) ) 
(T  (ERROR_HANDLER  (QUOTE  EXP_BaQL) 

(LIST  (CADR  EXP)  (QUOTE  in)  EXP] 
((AND  (EQ  TAG  (QUOTE  iter)) 
(EQ  (LENGTH  EXP)  4) 
(EQ  (CADDR  EXP)  (QUOTE  -; ) ) ) 
(LIST  (QUOTE  closure) 
(QUOTE  ?x) 

(LIST  (QUOTE  repeat) 
(CADDDR  EXP) 
(QUOTE  until_not) 
(CADR  EXP)  E) ) 
( (EQ  TAG  (QUOTE  repeat)) 

(RPL_REPEAT  EXP  E) ) 
((AND  (LISTP  (CADR  EXP)) 

(EQ  (LENGTH  (CADR  EXP))  2) 
(EQ  (CADADR  EXP)  (QUOTE  bar))) 
(LIST  (QUOTE  closure) 
(QUOTE  ?x) 
(LIST  (LIST  (CAR  EXP) 

(QUOTE  ?k) ) 
(CAADR  EXP) 
(LIST  (CADDR  EXP) 

(QUOTE  ?K) ) )  E) ) 
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( (EQ  TAG  (QUOTE  reduce) ) 

(ARRAY_REDUCT I ON  EXP  E) ) 
(T  (ERROR_HANDLER 

(QUOTE  BAD_SYNTAX)  EXP]) 

(MAPEV 

************************************************************ 

args:        L,  E 

calls:      MAPCAR,  EV 

called  by:  EVSEQ 

binds:       X 

comments:   Given  the  list,  L,  and  its  environment,  E,  it 
returns  a  list  o-F  evaluated  elements. 
************************************************************ 

CLAMBDA  (L  E) 

'   (MAPCAR  L  (QUOTE  (LAMBDA  (X)   (EV  X  ED) 

(EVRANGE 

************************************************************ 
args:       LOW,  HIGH 
calls:      NUMBERP,  LEQ ,  ERROR_HANDLER,  LIST,  CONS, 

DIFFERENCE 
called  by:  EV_SPECI AL_CASES ,  EVSEQ 
binds:      L 

comments:   Enumerates  the  range  -from  LOW  to  HIGH  and 
returns  the  list  of  numbers. 
************************************************************ 
CLAMBDA  (LOW  HIGH) 
(PROG  (L) 

(SETQ  L  NIL) 
(COND 
((AND  (NUMBERP  LOW) 
(NUMBERP  HIGH) 
(LEQ  LOW  HIGH) ) 
(GO  MAKE_LIST) ) 
(T  (ERROR_HANDLER  (QUOTE  BAD_RAN6E) 
(LIST  LOW  HIGH) ) 
(GO  EXIT) ) ) 
MAKE_LIST 
( COND 
( (EQ  LOW  HIGH)   (SETO  L  (CONS  LOW  L) ) ) 
(T  (SETQ  L  (CONS  HIGH  D) 

( SETQ  HIGH  ( D I FFERENCE  HIGH  1) ) 
(GO  MAKE_LIST) ) ) 
EX  IT (RETURN  LJ) 
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(EVSEQ 

************************************************************ 
args:       SQ ,  E 
calls:      MEMBER,  GREATERP ,  ERROR_HANDLER ,  LENGTH,  MAPEV , 

EV,  EVRANGE,  SEQ_TO_REL ,  LIST_TO_REL 
called  by:  EV_SPECIAL_CASES 
binds:      TAG,  S,  LOW,  HIGH 
uses  -free:  ERRORCODE 

comments:   Takes  the  tagged  sequence  or  sequence  range, 
SQ,  its  environment,  E,  and  returns  a  tagged 
evaluated  relation. 
************************************************************ 
C LAMBDA  (SQ  E) 

(PROG  (TAG  S  HIGH  LOW) 

(SETQ  TAG  (CAR  SQ) ) 
(SETQ  S  (CDR  SQ) ) 
CCOND 
((AND  (MEMBER  TAG  (QUOTE  (seq  list))) 
(GREATERP  (LENGTH  S)  D) 
(SETQ  S  (MAPEV  S  E) ) 
(GO  COERCE) ) 
(T  (COND 

((AND  (EQ  (LENGTH  S)  3) 

(EQ  (CADR  S)   (QUOTE  to))) 
(SETQ  LOW  (EV  (CAR  S)  E) ) 
(SETQ  HIGH  (EV  (CADDR  S)  E) ) 
(COND 

(  (EQ  ERRORCODE  (QUOTE  ER.RORFREE)  ) 
(SETQ  S  (EVRANGE  LOW  HIGH)) 
(GO  COERCE) ) 
(T  NIL) ) ) 
(T  (ERROR_HANDLER 

(QUOTE  BAD_SEQ)  S: 
COERCE 

( RETURN  ( COND 

C(EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

((MEMBER  TAG  (QUOTE  (seq  seqrange) ) ) 

(SEQ_TO_REL  S) ) 
(T  (LIST_TO_REL  S: 
(T  NIL3) 
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(INFIXOP 


by: 


args: 
calls: 
cal led 
binds: 
uses  -free 
comments: 


CONS,  RPAPPLY,  ERROR_HANDLER 


lEXP,  ENV-I 

EV,  TYPE,  LIST, 

EV 

L,  OP,  R,  A 

ERRORCODE 

Performs  pre— processing  for  evaluation.   The 

arguments,  L  and  R,  and  operator,  OP,  Are 

extracted  from  lEXP  and  evaluated  in  ENV— I,  the 

environment.   The  argument  list  is  created  and 

is  sent  with  the  operator  to  be  evaluated. 

CLAMBDA  (lEXP  ENV-I) 
•   (PROG  (L  OP  R  A) 

(SETQ  L  (EV  (CAR  lEXP)  ENV-I) ) 
(SETQ  OP  (EV  (CADR  lEXP)  ENV-I) ) 
(SETQ  R  (EV  (CADDR  lEXP)  ENV-I) ) 
(RETURN  (COND 

((EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

( (EO  (TYPE  OP)   (QUOTE  closure)) 
(SETQ  A  (LIST  (QUOTE  Erel ) 
(CONS  1  L) 
( CONS  2  R ) ) ) 
(RPAPPLY  OP  A) ) 
(T  (ERROR_HANDLER  (QUOTE  EXP_FUNC) 

(CADR  lEXP]) 


(PREFI 

args 
call 
call 
bind 
uses 
comm 

CLAM 
(P 


XOP 

:        PEXP,  ENV-P 

s:      EV,  TYPE,  RPAPPLY,  ERROR_HANDLER 

ed  by:  EV 

s:      OP,  ARG 

ERRORCODE 


Same  as  INFIXOP,  except  for  prefix  operators, 


free: 
ents: 

3D A  (PEXP  ENV-P) 
ROG  (OP  ARG) 

(SETQ  OP  (EV  (CAR  PEXP)  ENV-P) ) 
(SETQ  ARG  (EV  (CADR  PEXP)  ENV-P)) 
(RETURN  (COND 

( (EQ  ERRORCODE  (QUOTE  ERRORFREE)) 
(COND 

( (EQ  (TYPE  OP)   (QUOTE  closure)) 

(RPAPPLY  OP  ARG) ) 
(T  (ERROR_HANDLER 

(QUOTE  EXP  FUNC)   (CAR  PEXPl) 
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(RP APPLY 
************************************************************ 

args:       F,  A   (Evaluated  form) 

calls:      ATOM,  ERROR_HANDLER,  LENGTH,  BIF_APPLY,  C0^4S, 
DIFFERENCE,  BINDARGS,  APPEND,  LIST,  EV 

called  by:  INFIXOP,  PREFIXOP,  ARRAY_REDUCTION ,  FILTER, 
MAP IMG,  MAPRP,  MAPRP_INV,  MAP_ISOMORPHISM , 
RPL_REPEAT 

binds:      FORMALS,  EE,  LE 

uses  -free:  ERRORCODE 

coiTifnents:   Determines  if  F  is  a  LISP  defined  function  or 
i ntensional 1 y  defined  function.   Evaluates  the 
latter  with  the  argument,  A,  and  sends  the 
former  with  argument  to  BIF_APPLY. 

CLAMBDA  (F  A) 

<PROG  (FORMALS  LE  EE) 
(RETURN  (CCND 

( (EQ  (LENGTH  F)  2) 
(BIF_APPLY  FA)) 
(T  (SETQ  FORMALS  (CADR  F) ) 
CCOND 

C (ATOM  FORMALS) 

(SETQ  EE  (CONS  (CONS  FORMALS  A) 

(CADDDR  FD 
(T  (COND 

C ( EQ  ( D I FFERENCE  ( LENGTH  A )  1) 
(LENGTH  FORMALS) ) 
(SETQ  LE  (BINDARGS  FORMALS  A)) 
(SETQ  EE  (APPEND  LE  (CADDDR  F: 
(T  (ERROR_HANDLER  (QUOTE  PAR AM) 
(LIST  (QUOTE  (number  of 

parameters  in  error] 
(COND 

( (EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(EV  (CADDR  F)  EED) 


(BINDARGS 

args:  F,  A 

calls:  MAP2CAR 

called  by:  RPAPPLY 

CLAMBDA  (F  A) 

(MAP2CAR  F  (CDR  A) 

(QUOTE  (LAMBDA  (X  Y)   (CONS  X  (CDR  YD) 
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(BIF_ APPLY 

args:       F,  ARG 

calls:      MEMB,  hJUMBERP,  ZEROP,  ATOM,  NUMERIC_SET, 

COERCE_TO_REL,  TYPE,  LENGTH,  ERROR_HANDLER , 
SEL,  LIST,  PLUS,  DIFFERENCE,  TIMES,  QUOTIENT, 
TF,  GREATERP,  LEQ,  GEO,  CONS,  INTERSECTION, 
UNION,  LDIFFERENCE,  CART_PROD ,  DO_SUBSET , 
REQUAL,  RNOT,  MEM,  RELATIVE_PRODUCT , 
CONSTRUCT I ON ,  ARR A Y_CONC ATENAT I QN , 
SEQ_TO_ARRAY,  SELECT_ALL,  MAPRP ,  FORM_PAIR, 
MAP IMG,  MAPRP_INV,  MAP_ISOMORPHISM ,  FILTER, 
SUPERSCRIPT,  FILE_READ,  CONVERSE,  DOMAIN, 
RANGE,  MAKE_UNIQUE,  REVERSE_ARRAY , 
ARRAY_TO_SEQ,  CURRY_EXT,  UNCURRY_EXT,  HEAD, 
TAIL,  MIN_SET,  MAX_SET,  SEQ_TO_REL ,  SORT, 
LIST_TO_REL,  LESSP 

called  by:  RP APPLY 

binds:      OP,  L,  R 

uses  -free:  ENV-P ,  PEXP,  ERRORCODE ,  SETOP ,  I  EXP,  NUMOP , 
ENV- I ,  B I FTAG_ INFIX 

comments:   Evaluates  all  built— in  LISP  defined  operators, 

[LAMBDA  (F  ARG) 
(PROG  (L  R  OP) 

(SETQ  OP  (CADR  F) ) 
(RETURN  (COND 

[(MEMB  OP  BIFTAG_INFIX) 
(COND 

((AND  (NOT  (EQ  (TYPE  ARG) 
(QUOTE  Erel) ) ) 
(NOT  (EQ  (LENGTH  ARG)  3) ) ) 
(ERROR_HANDLER 

(QUOTE  BAD_ARGS)  ARG)) 
(T  (SETQ  L  (SEL  ARG^  1) ) 
(SETQ  R  (SEL  ARG' 2) ) 
(COND 

C(EQ  OP  (QUOTE  reduction)) 
(COND 

( (EQ  (TYPE  L) 

(QUOTE  closure) ) 
(LIST  (QUOTE  closure) 
(QUOTE  ?A) 

(LIST  (QUOTE  reduce) 
(QUOTE  ?A) 
(QUOTE  by) 
L 

(QUOTE  from) 
R )  ENV- I ) ) 
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(T  (ERROR_HANDLER 

(QUOTE  EXP_FUNC) 

(CAR  arg: 

C (MEMB  QP  NUMOP) 
(CDND 

C (AND  (NUMBERP  L) 
(NUMBERP  R) ) 
(COND 

( (EQ  OP  (QUOTE  +) ) 

(PLUS  L  R) ) 
( (EQ  OP  (QUOTE  -) ) 

(DIFFERENCE  L  R) ) 
( (EQ  OP  (QUOTE  *) ) 

(TIMES  L  R) ) 
C (EQ  OP  (QUOTE  /) ) 
(COND 

( (ZEROP  R) 

(ERROR_HhNDLER 

(QUOTE  ZER0_DIV) 
(CADDR  IEXP))) 
(T  (QUOTIENT  L    Rl 
( (EQ  QP  (QUOTE  <) ) 

(TF  (LESSP  L  R) ) ) 
( (EQ  OP  (QUOTE  >) ) 

(TF  (GREATERP  L  R) ) ) 
( (EQ  OP  (QUOTE  <=) ) 

(TF  (LEQ  L  R) ) ) 
( (EQ  OP  (QUOTE  >=) ) 

(TF  (GEQ  L  R) ) ) 
(T  (QUOTE  impossible! 
(T  (ERR0R_HANDLER 

(QUOTE  EXP  NUM) 


(LIST 

(CAR  IEXP) 

(QUOTE  or) 

(CADDR  IEXP] 

C (EQ  OP  (QUOTE 

or)  ) 

(COND 

( ( OR  ( EQ  L 

(QUOTE  true) ) 

(EQ  R 

(QUOTE  true) ) 

(QUOTE  true) ) 
(T  (QUOTE  -False] 
I (EQ  OP  (QUOTE  and) ) 
(COND 

((AND  (EQ  L  (QUOTE  true)) 
(EQ  R  (QUOTE  true) ) ) 
(QUOTE  true) ) 
(T  (QUOTE  -false] 
H (MEMB  OP  SETOP) 
(COND 

CCAND  (MEMB  (TYPE  L) 

(QUOTE  (Eset  Erel ) ) ) 
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(MEMB  (TYPE  R) 

(QUOTE  (Eset  Erell 
(COND 

C (EQ  OP  (QUOTE  union)) 
(COND 

C  (OR  (EQ  (CAR  L) 

(QUOTE  Eset) ) 
(EQ  (CAR  R) 

(QUOTE  Eset) ) ) 
(CONS  (QUOTE  Eset) 

(UNION  (CDR  L) 
(CDR  R] 
(T  (CONS  (QUOTE  Ersl ) 

(UNION  (CDR  L) 
(CDR  RD 
C (EQ  OP  (QUOTE  i nterssct i an ) ) 
(COND 

C (OR  (EQ  (CAR  L) 

(QUOTE  Erel ) ) 
(EQ  (CAR  R) 

(QUOTE  Erel) ) ) 
(CONS  (QUOTE  Erel) 
(INTERSECTION  (CDR  L) 
(CDR  RD 
(T  (CONS  (QUOTE  Eset) 

(INTERSECTION  (CDR  L) 
(CDR  Rj 
C  (EQ  OP  (QUOTE  setdi-f-f)) 
( COND 

C (EQ  (CAR  L) 

(QUOTE  Eset) ) 
(CONS  (QUOTE  Eset) 
(LDIFFERENCE  (CDR  L) 
(CDR  R] 
(T  (CONS  (QUOTE  Erel) 

(LDIFFERENCE  (CDR  L) 
(CDR  R1 
C (EQ  OP  (QUOTE  cart) ) 
(CONS  (QUOTE  Erel) 
(CART_PROD 
(CDR  L) 
(CDR  RJ 
n(EQ  OP  (QUOTE  ! subset)) 
(COND 

( (GREATERP  (LENGTH  L) 
( LENGTH  R ) ) 
(QUOTE  -false)  ) 
(T  (DO_SUBSET 
(CDR  L) 

(CDR  r: 
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C (ED  OP  (QUOTE  subset)) 
(COND 

( (GEQ  (LENGTH  L) 
(LENGTH  R) ) 
(QUOTE  -false)  ) 
(T  (DO_SUBSET 
(CDR  L) 

(CDR  r: 

(T  (QUOTE  impossible: 
(T  (ERR0R_HANDLER 

(QUOTE  EXP_SET) 
(LIST  (CAR  lEXP) 
(QUOTE  or) 
(CADDR  IEXP: 
( (EQ  OP  (QUOTE  =) ) 

(REQUAL  L  R  ENV-I) ) 
( (ED  OP  (QUOTE  <>) ) 

(RNOT  (REQUAL  L  R  ENV-I))) 
( (EQ  OP  (QUOTE  member)) 

(MEM  L  R) ) 
((ED  OP  (QUOTE  nomem) ) 

(RNOT  (MEM  L  R) ) ) 
C (MEMB  OP 

(QUOTE  (7.!  construction 

concatenation) ) ) 
(COERCE_TO_REL  L) 
(COERCE_TO_REL  R) 
( COND 

( (EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

C  (EQ  OP  (QUOTE  7.!  )  ) 
(CONS  (QUOTE  Erel) 

( RELAT I VE_PRODUCT 
(CDR  L) 

(CDR  r: 

( (EQ  OP  (QUOTE  construction)) 

(CONSTRUCTION  L  R) ) 
( (EQ  OP  (QUOTE  concatenation)) 
( ARRAY_CONCATENAT I CN 
L  Rl 
C(MEMB  OP  (QUOTE  (sel  seq_to_array 
5elect_all  rel_prod))) 
(COERCE_TO_REL  L) 
(COND 

((EQ  ERRORCODE  (QUOTE  ERRORFREE)) 
(COND 

( (EQ  OP  (QUOTE  sel ) ) 

(SEL  L  R) ) 
((EQ  OP  (QUOTE  seq_to_array) ) 
(SEQ  TO  ARRAY  L  R) ) 
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((EQ  OP  (QUOTE  5elect_all)) 

(SELECT_ALL  R  (CDR  L) ) ) 
( (EQ  OP  (QUOTE  rel_prod)) 
(COND 

Z (EQ  (TYPE  R) 

(QUOTE  closure) ) 
(CONS  (QUOTE  Erel  ) 

(MAPRP  R  (CDR  LD 
(T  (ERROR_HANDLER 

(QUOTE  EXP_FUNC)  Rl 
( (EQ  OP  (QUOTE  : ) ) 
(FORM_PAIR  L  R) ) 
C (EQ  OP  (QUOTE  img) ) 
( COND 

(CAND  (EQ  (TYPE  L) 

(QUOTE  clQBLire)  ) 
(MEMB  (TYPE  R) 

(QUOTE  (Eset  Erel 3 
(CONS  (QUOTE  Eset) 

(MAP IMG  L  (CDR  R) 
ENV-I) ) ) 
(T  (COND 

( (EQ  (TYPE  L) 

(QUOTE  closure) ) 
(ERROR_HANDLER 
(QUOTE  EXP_SET) 
(CADDR  I EXP) ) ) 
(T  (ERROR_HANDLER 

(QUOTE  EXP_FUNC) 
(CAR  I EXP] 
[(MEMB  OP  (QUOTE  (rel _prod_i nv 

isomorphism) ) ) 
(COERCE_TO_REL  R) 
( COND 

C ( AND  ( EQ  ( TYPE  L ) 

(QUOTE  closure) ) 
(EQ  ERRORCODE 

(QUOTE  ERRORFREE) ) ) 


(T 


(COND 

C (EQ  OP 

( QUOTE  r  e 1 _p r  od _  i  n  v ) ) 

(CONS 

(QUOTE  Erel ) 

(MAPRP  INV  L 

(CDR  r: 

( (EQ  OP 

(QUOTE  isomorphism)) 

( CONS 

(QUOTE  Erel ) 

(MAP  ISOMORPHISM 

L  (CDR  r: 

(COND 

(  (NOT 

(EQ  (TYPE  L) 

(QUOTE  closure) ) ) 
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(ERROR_HANDLER 

(QUOTE  EXP_FUNC)  LI 
C  (EQ  OP  (QUOTE  -Filter)) 
(COND 

(HAND  (EQ  (TYPE  L) 

(QUOTE  closure) ) 
(MEMB  (TYPE  R) 

(QUOTE  (Eset  Ersll 
(CONS  (CAR  R) 

(FILTER  L  (CDR  R) 
ENV-I) ) ) 
(T  (COND 

( (EQ  (TYPE  L) 

(QUOTE  closure) ) 
(ERROR_HANDLER 
(QUOTE  EXP_SET) 
(CADDR  I EXP) ) ) 
(T  (ERROR_HANDLER 

(QUOTE  EXP_BOOL) 
(CAR  lEXP] 
( (EQ  OP  (QUOTE  superscript)) 
(SUPERSCRIPT  L  R: 
(T  (COND 

( (EQ  OP  (QUOTE  not) ) 

(RNOT  ARG) ) 
(  (EQ  OP  (QUOTE  -File)  ) 

(FILE_READ  ARG) ) 
C (EQ  OP  (QUOTE  unitset)) 
(COND 

(OR  (ATOM  ARG)   (STRINGP  ARG) 

(LIST  (QUOTE  Eset)  ARG)) 
(T  (COND 

( (MEMB  (CAR  ARG) 

(QUOTE  (Eset  Erel  closure))) 
(LIST  (QUOTE  Eset)  ARG)) 
(T  (LIST  (QUOTE  Erel)  ARG3 
C (MEMB  OP  (QUOTE  (uni tset_sel ect 

el ementsel ect ) ) ) 
(COND 

C (MEMB  (TYPE  ARG) 

(QUOTE  (Eset  Erel ) ) ) 
(COND 

C (EQ  OP  (QUOTE  uni tset_5el ect ) ) 
(COND 

( (EQ  (LENGTH  (CDR  ARG)) 
1) 
(CADR  ARG) ) 
(T  (ERRQR_HANDLER 

(QUOTE  EXP_UNITSET) 
(CADR  PEXP3 
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< (ED  OP  (QUOTE  elementselect) ) 
(COND 

( (NULL  (CDR  ARG) ) 
(ERROR_HANDLER 

(QUOTE  EXP_NEMPTY) 
(CADR  PEXP) ) ) 
(T  (CADR  ARG: 
(T  (ERROR_HANDLER 

(QUOTE  EXP_SET) 

(CADR  pexp: 

C(EQ  OP  (QUOTE  cardinality)) 
(COND 

( (MEMB  (TYPE  ARG) 

(QUOTE  (Eset  Erel ) ) ) 
(LENGTH  (CDR  ARG) ) ) 
(T  (ERROR_HANDLER 

(QUOTE  EXP_SET) 

(CADR  pexp: 

C (MEMB  OP  (QUOTE  (converse  rng  dom 

array_tD_seq    run 
r ever se_ar ray 
curry_e>;t 
uncurry_ext) ) ) 
(COERCE_TO_REL    ARG) 
(COND 

( (EQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(COND 

( (EQ  OP  (QUOTE  converse) ) 

(CONVERSE  ARG) ) 
( (EQ  OP  (QUOTE  dom) ) 

( DOMA I N  ARG ) ) 
( (EQ  OP  (QUOTE  rng) ) 

(RANGE  ARG) ) 
C (EQ  OP  (QUOTE  run) ) 
(COND 

(CEQ  [LENGTH  (MA:<E_UNIQUE 
(CDR  (RANGE  ARG) 
NIL  ENV-P] 
(LENGTH  (CDR  (RANGE  ARG: 
(QUOTE  true) ) 
(T  (QUOTE  -False: 
( (EQ  OP  (QUOTE  r ever 5e_ar ray) ) 

(REVERSE_ARRAY  ARG) ) 
( (EQ  OP  (QUOTE  array_tQ_seq) ) 

(ARRAY_TO_SEQ  ARG) ) 
((EQ  OP  (QUOTE  curry_eKt)) 

(CURRY_EXT  ARG) ) 
((EQ  OP  (QUOTE  uncurry_ext) ) 
(UNCURRY_EXT  ARG: 
( (EQ  OP  (QUOTE  Hd) ) 
(HEAD  ARG) ) 
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( (EQ  OP  (QUOTE  Tl) ) 

(TAIL  ARG) ) 
C (MEMB  OP  (QUOTE  (min  max  unique_5et)) 
(COND 

C (EQ  (TYPE  ARG) 

(QUOTE  Eset) ) 
(COND 

( (EQ  OP  (QUOTE  min) ) 

(MIN_SET  ARG) ) 
( (EQ  OP  (QUOTE  max) ) 

(MAX_SET  ARG) 
( (EQ  OP  (QUOTE  unique_set)) 
(riAKE_UNIQUE  (CDR  ARG) 
NIL  EN'v'-P: 
(T  (ERROR_HANDLER 

(QUOTE  EXP_SET)  ARGD 
((MEMB  OP  (QUOTE  (rsort  sort))) 
(COND 

r (NUMERIC_SET  (CDR  ARG)) 
( COND 

C (EQ  OP  (QUOTE  rsort)) 
(CONS  (QUOTE  Erel) 
(SEQ_TO_REL 

(SORT  (CDR  ARG) 

(QUOTE  lessp: 

(T  (CONS  (QUOTE  Ersl ) 
(LIST_TO_REL 

(SORT  (CDR  ARG) 
(QUOTE  LESSPj 
(T  (ERROR_HANDLER 

(QUOTE  EXP  NSET)  ARG]) 


( ARRAY_CONCATENAT I ON 

args:       Al ,  A2   (Tagged  relations) 

calls:       NUMER I C_SET, ^DOMAIN,  REVERSE,  APPEND,  MAPCAR , 

PLUS,  CONS,  ERROR_HANDLER,  LIST 
called  by:  BIF_APPLY 
binds:       INDEX,  X 
comments:   Given  two  arrays  (relation  with  numeric  inde;;), 

Al  and  A2 ,  returns  a  single  array    which  is  the 

concatenation  o-f  Al  to  A2. 

C LAMBDA  (Al  A2) 
(COND 

CCAND  (NUMERIC_SET  (CDR  (DOMAIN  Al))) 
(NUMERIC_SET  (CDR  (DOMAIN  A2: 
(PROG  (INDEX) 

(SETQ  INDEX  (CAAR  (REVERSE  Al))) 
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(RETURN  (APPEND  Al  (MAPCAR  (CDR  A2) 

(QUOTE  (LAMBDA  (X)  (SETQ  INDEX  (PLUS  1  INDEX)) 

(CONS  INDEX  (CDR  XI 
(T  (ERROR_HANDLER 

(QUOTE  EXP_ARRAY) 

(LIST  Al  (QUOTE  or)  A2:) 

( ARRAY_REDUCT I ON 

args:       EXP,  EA 

calls:      COERCE_TO_REL,  MAPCAR,  ERROR_HANDLER ,  EV , 
RANGE,  RPAPPLY,  LIST,  CONS 

called  by:  EV_SPECIAL_CASES 

binds:      ARRAY,  FNC ,  START,  ARGS ,  ANS ,  X 

comments:   Given  an  expression,  EXP,  o-f  the  -Form: 

"reduce  Array  by  Function  -from  Start  i  n_Point" 
created  by  the  "red"  operator,  returns  a  value 
by  extracting  the  -function,  starting  point  and 
array,  to  reduce  the  values  in  the  a.rr3.y    by 
repeated  applications  of  the  function. 

: LAMBDA  (EXP  EA) 

(PROG  (ARRAY  FNC  START  ARGS  ANS) 

(SETQ  ARRAY  (EV  (CADR  EXP)  EA) ) 
(COND 
( (COERCE_TO_REL  ARRAY) 
(SETQ  FNC  (CADDDR  EXP)) 
(SETQ  START  (CADDDR  (CDDR  EXP))) 
(SETQ  ARGS  (CDR  (RANGE  ARRAY) ) ) 
(SETQ  ANS  START) 
CMAPCAR  ARGS  (QUOTE  (LAMBDA  (X) 

(SETQ  ANS  (RPAPPLY  FNC  (LIST  (QUOTE  Erel ) 

(CONS  1  ANS) 

(CONS  2  x: 

(RETURN  ANS) ) 


(ARRAY_TO_SEQ 

args:       ARRAY  (Tagged  relation) 
calls:      SET,  RANGE,  CONS,  REVERSE 
called  by:  BIF_APPLY 
binds:      SI,  S2 ,  SEQ 

comments:   Converts  the  values  of  an  arr^y    into  a  sequence 
************************************************************ 
[LAMBDA  (ARRAY) 

(PROG  (SI  S2  SEQ) 

(SETQ  SI  (CDR  (RANGE  ARRAY))) 

(SETQ  S2  (CDR  SI) ) 

(SET  SEQ  NIL) 
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LOOP(COND 

C (NULL  S2) 

(RETURN  (CONS  (QUOTE  Erel )  (REVERSE  SEQD 
(T  (SETQ  SEQ  (CONS  (CONS  (CAR  SI)  (CAR  S2) )  SEQ) ) 
(SETQ  SI  (CDR  SI) ) 
(SETQ  S2  (CDR  S2) ) 

(GO  loop:) 


(CART_PR0D 

************************************************************ 
args:       A,  B  (Untagged  sets) 
calls:      APPEND,  MAPCAR,  CONS,  CART_PROD 
called  by:  BIF_APPLY,  CART_PROD 
binds:      X 
************************************************************ 
CLAMBDA  (A  B) 
(COND 

( (NULL  A)  NIL) 

(T  (APPEND  C MAPCAR  B  (QUOTE  (LAMBDA  (X) 

(CONS  (CAR  A)  X: 
(CART  PROD  (CDR  A)  Bl) 


(CONSTRUCTION 

************************************************************ 
args:        TBLl ,  TBL2  (Tagged  relations) 

calls:      CONS,  MAPCAR,  INTERSECTION,  DOMAIN,  LIST,  SEL 
called  by:  BIF_APPLY 
binds:       X 

comments:   Given  two  tables,  returns  a  table  which  relates 
every  common  domain  element  o-f  TBLl  and  TBL2  to 
a  list  containing  the  range  element  from  each 
table,  associated  with  the  domain  element. 
************************************************************ 
CLAMBDA  (TBLl  TBL2) 
(CONS  (QUOTE  Erel) 

(MAPCAR  (CDR  (INTERSECTION  (DOMAIN  TBLl) 

(DOMAIN  TBL2) ) ) 
(QUOTE  (LAMBDA  (X)   (CONS  X  (LIST  (QUOTE  Erel) 

(CONS  1  (SEL  TBLl  X) ) 
(CONS  2  (SEL  TBL2  XI) 
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(CONVERSE 
************************************************************ 

args:       R  (Tagged  relation) 

calls:      CONS,  REVERSE,  MAPCAR 

called  by:  BIF_APPLY,  SUPERSCRIPT 

binds:      X 

comments:   Given  a  relation,  R,  returns  a  relation  with 
the  range  and  domain  inverted. 

CLAMBDA  (R) 

(CONS  (CAR  R) 

(REVERSE  (MAPCAR  (CDR  R) 

(QUOTE  (LAMBDA  (X) 

(CONS  (CDR  X) 
(CAR  X]) 

(CURRY_EXT 

args:       TBL  (Tagged  relation) 

calls:      BINARY_LIST,  MAPCAR,  CONS,  REVERSE,  LOOKUP, 
CURRY_ELEMENT,  LDIFFERENCE 

called  by:  BIF_APPLY 

binds:      TAG,  PTBL ,  CTBL ,  FIRST,  KEY,  SUBTBL,  X 

comments:   Given  a  table  which  represents  an  extensional 
Lincurried  function,  i.e.,  every  domain  element 
is  a  binary  list  and  every  range  element  is  the 
result  o-f  the  represented  -function  on  the  argu- 
ments in  the  list,  returns  a  table  which  repre- 
sents the  curried  version  o-f  the  original  TBL. 

CLAMBDA  (TBL) 

(PROG  (PTBL  TAG  FIRST  KEY  SUBTBL  CTBL) 
(SETQ  TAG  (CAR  TBL) ) 
(SETQ  PTBL  (CDR  TBL) ) 
(SETQ  CTBL  NIL) 
LGQprcOND 

C (NULL  PTBL) 

(RETURN  (CONS  TAG  (REVERSE  CTBL: 
(T  (SETQ  FIRST  (CAR  PTBL) ) 
(COND 

( (BINARY_LIST 

(CAR  FIRST) ) 
(SETQ  KEY  (LOOKUP  1  (CAR  FIRST) ) ) 
(SETQ  SUBTBL  NIL) 

[MAPCAR  PTBL  (QUOTE  (LAMBDA  (X) 
(COND 

C (BINARY_LIST  (CAR  X)) 
(COND 

( ( EQ  ( CDADAR  X )  KEY ) 

(SETQ  SUBTBL  (CONS  X  SUBTBL j 

(T  (GO  exit: 


197 


(SETQ  CTBL  (CONS  (CURRY_ELEMENT 

KEY  SUBTBL)  CTBL) ) 
(SETQ  PTBL  (LDIFFERENCE  PTBL  SUBTBL) ) ) 

(T  (GO  exit: 

(GO  LOOP) 

exit:) 

(DOMAIN 

************************************************************ 
args:       R  (Tagged  relation) 
calls:      CONS,  MAPCAR ,  CAR 

called  by:  BIF_APPLY,  ARRAY_CONCATENATION,  CONSTRUCTION, 
reflex  I VE_TR ANS I T I VE_CLOSURE ,  REVERSE, ARRAY , 
SEQ_TO_ARRAY 
comments:   Returns  a  tagged  set  o-F  the  le-ft  members  o-f  the 
relation,  R. 
************************************************************ 
C LAMBDA  (R) 

(CONS  (QUOTE  Eset)  (MAPCAR  (CDR  R)   (QUOTE  CARD) 

(Da_3UBSET 

args:       SI,  S2  (Untagged  relation  or  set) 

calls:      MEMBER,  DO_SUBSET 

called  by:  BIF_APPLY,  DO_SUBSET,  REQUAL 

C LAMBDA  (SI  S2) 
(COND 

((NULL  SI)  (QUOTE  true)) 
((MEMBER  (CAR  SI)  S2) 

(DO_SUBSET  (CDR  SI)  S2)) 
(T  (QUOTE  -False:) 

(FILE_READ 

args:       FNAME  (Unix  -Filename) 

calls:       WRITE,  INFILE,  TERPRI ,  CLOSEALL ,  MKATOM , 

INFILEP,  READ 
called  by:  BIF_APPLY 
binds:       INPUT 
comments:   Reads  from  a  -File,  a  previously  stored  RPL  data 

el ement . 

C LAMBDA  (FNAME) 

(SETQ  FNAME  (MKATOM  FNAME) ) 
(PROG  (INPUT) 

(SETQ  INPUT  (INFILEP  FNAME)) 
( COND 
( (NULL  INPUT) 

(WRITE  (QUOTE  (-File  not  -Found))) 
(GO  EXIT) ) ) 
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(INFILE  INPUT) 
(RETURN  (READ  INPUT)) 
EXIT(TERPRI) 

(CLOSEALL  nil:) 

(FILE_WRITE 

************************************************************ 
args:       FNAME  (Unix  -filename) 

EXP    (Any  RPL  expression) 
calls:      OUTFILE,  PRINT,  CLOSEALL,  MKATOM ,  OUTFILEP 
called  by:  EXECUTE 
binds:      OUTPUT 

comments:   Writes  the  evaluated  EXP  to  the  file  FNAME. 
************************************************************ 
[LAMBDA  (FNAME  EXP) 
-   (SETQ  FNAME  (MKATOM  FNAME) ) 
(PROG  (OUTPUT) 

(SETQ  OUTPUT  (OUTFILEP  FNAME)) 
(OUTFILE  OUTPUT) 
(PRINT  EXP  OUTPUT) 
(CLOSEALL  nil:) 

(FILTER 

************************************************************ 
args:       P  (RPL  boolean  predicate,  evaluated) 

S  (Untagged  set  or  relation) 
calls:      MAPCAR,  RPAPPLY,  CONS,  REVERSE 
called  by:  BIF_APPLY 
binds:      FSET,  X,  ARG 
uses  -free:  ERRORCODE,  FILTER_ON 
comments:   Returns  S  or  a  subset  o-f  S,  based  upon  the 

result  of  applying  the  boolean  predicate,  P,  to 
each  element  of  S. 
************************************************************ 
E LAMBDA  (P  S) 

(PROG  (FSET  ARG) 

(SETQ  FSET  NIL) 
(SETQ  FILTER_ON  T) 
C MAPCAR  S  (QUOTE  (LAMBDA  (X) 
CCOND 
( (EQ  (RPAPPLY  P  X)   (QUOTE  true)) 
(SETQ  FSET  (CONS  X  FSET: 
(SETQ  ERRORCODE  (QUOTE  ERRORFREE: 
(SETQ  FILTER_0N  NIL) 
(RETURN  (REVERSE  FSET:) 
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(FNC_BODY 

************************************************************ 
args:       N 

calls:      LIST,  DIFFERENCE 
called  by:  REPEAT_COMPOSITION 
binds:      ANS 

comments:   An  auxiliary  function  to  REPEAT_COMPOSITION 
which  creates  the  physical  closure  with  N 
compositions  o-F  a  -function  -f . 
************************************************************ 
C LAMBDA  (N) 
(PROG  (ANS) 

(SETQ  ANS  (LIST  (QUOTE  -F )  (QUOTE  x))) 
LOOP(COND 

( (EQ  N  0)   (RETURN  ANS)) 
(T  (SETQ  ANS  (LIST  (QUOTE  -f )  ANS)) 
(SETQ  N  (DIFFERENCE  N  1)) 
(GO  L00P3) 

(FORM_PAIR 

args:       X  (An  elementary  pair) 
cal 1 s :      ERROR_HANDLER 
called  by:  BIF_APPLY 
********************************************************* 
CLAMBDA  (X  Y)  (CONS  X  YH) 

(HEAD 

args:       X,  Y  (Anything) 
calls:      CONS 
called  by:  BIF_APPLY 

CLAMBDA  (X) 
(CCND 

((AND  (LISTP  X)   (NOT  (NULL  X)))   (CAR  X)) 
(T  (ERROR_HANDLER  (QUOTE  EXP_PAIR)  X3) 

(MAP IMG 

args:       F  (RPL  function,  evaluated  form) 

S  (Untagged  set  of  relation) 
calls:       MAPCAR ,  RP APPLY 
called  by:  BIF_APPLY 
binds:       X 
comments:   Returns  an  untagged  set  of  results  of  applying 

F  to  each  member  of  S. 
****if************************************+******** ********** 
CLAMBDA  (F  S) 

(MAPCAR  S  (QUOTE  (LAMBDA  (X)   (RPAPPLY  F  XD) 
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(MAPRP 

args;       F    (RPL  function,  evaluated  form) 
TBL  (Untagged  relation) 

calls:      MAPCAR,  CONS,  RP APPLY 

called  by:  BIF_APPLY 

binds:      X 

comments:   Returns  an  untagged  table  which  relates  each 

domain  element  of  TBL  to  the  result  of  applying 
F  to  the  associated  range  element. 

C LAMBDA  (F  TBL) 

(MAPCAR  TBL  (QUOTE  (LAMBDA  (X) 

(CONS  (CAR  X) 

(RP APPLY  F  (CDR  Xj) 

(MAPRP_INV 

************************************************************ 
args:       F    (RPL  function,  evaluated  form) 

TBL  (Untagged  relation) 
calls:      MAPCAR,  CONS,  RPAPPLY 
called  by:  BIF_APPLY  - 
binds:      X 

comments:   Returns  an  untagged  table  which  applys  F  to 
each  domain  element  of  TBL,  and  relates  this 
result  to  the  associated  range  element. 
************************************************************ 
C LAMBDA  (F  TBL) 

(MAPCAR  TBL  (QUOTE  (LAMBDA  (X) 

(CONS  (RPAPPLY  F  (CAR  X)) 
(CDR  x:) 

(MAP_ ISOMORPHISM 

************************************************************ 

args:       F    (RPL  function,  evaluated  form) 
TBL  (Untagged  relation) 


calls 


MAPCAR,  CONS,  RPAPPLY 


called  by:  BIF_APPLY 
binds:      X 

comments:   Returns  an  untagged  table  where  each  element  ii 
the  result  of  applying  F  to  both  the  left  and 
right  member  of  each  element  in  TBL. 
***********************************************************- 
r LAMBDA  (F  TBL) 

(MAPCAR  TBL  (QUOTE  (LAMBDA  (X) 

(CONS  (RPAPPLY  F  (CAR  X)) 
(RPAPPLY  F  (CDR  XD) 
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(MAX_SET 

************************************************************ 
args:       S  (Tagged  numeric  set) 

calls:      NUMERIC_SET,  GREATERP ,  MAPCAR,  T,  ERROR_HANDLER 
called  by:  BIF_APPLY 
binds:      SET,  MAX,  X 

comments :   Returns  the  maximum  member  o-f  the  set. 
************************************************************ 
C LAMBDA  (3) 

(PROG  (MAX  SET) 

(SETQ  SET  (CDR  S) ) 
(COND 
( (NUMERIC_SET  SET) 

(SETQ  MAX  (CAR  SET) ) 

C MAPCAR  SET  (QUOTE  (LAMBDA  (X) 

(COND 

( (GREATERP  X  MAX) 
(SETQ  MAX  Xj 
(RETURN  MAX) ) ) 
(T  (ERROR_HANDLER  (QUOTE  EXP_NSET)  SET!) 

(MEM 

*************************************************************** 
args:        X  (Anything) 

S  (A  tagged  set  or  relation) 
calls:    ■  TYPE,  MEMBER,  ERROR_HANDLER 
called  by:  BIF_APPLY 

comments:   Returns  true  if  X  is  a  member  o-f  S,  otherwise 
■false  is  returned. 

E LAMBDA  (X  S) 
(COND 

:■ MEMBER  (TYPE  S)  (QUOTE  (Eset  Erel ) ) ) 
(COND 

( (EQ  (MEMBER  X  S)  NIL)  (QUOTE  false)) 
(T  (QUOTE  true: 
(T  (ERROR  HANDLER  (QUOTE  EXP  SET)  SI) 


args:       S  (Tagged  numeric  set) 

calls:       NUMERIC_SET,  LESSP ,  MAPCAR,  ERRaR_HANDLER 
called  by:  BIF_hPPLY 
binds:      SET,  MIN,  X 

comments:   Returns  the  minimum  member  of  the  set. 
********************************************** *******^****** 
C LAMBDA  (S) 

(PROG  (MIN  SET) 

(SETQ  SET  (CDR  S) ) 
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(COND 
( (NUMERIC_SET  SET) 

(SETQ  MIN  (CAR  SET) ) 

CMAPCAR  SET  (QUOTE  (LAMBDA  (X) 

(CCND 

( (LESSP  X  MIN) 
(SETQ  MIN  X: 
(RETURN  MIN) ) 
(T  (ERROR_HANDLER  (QUOTE  EXP_NSET)  SETl) 

(RANGE 

************************************************************* 
args:       R  (Tagged  relation) 
calls:      CONS,  MAPCAR ,  CDR 
called  by:  BIF_APPLY,  ARRAY_REDUCTION,  ARRAY_TO_SEQ , 

REFLEX  I VE_TRANSITIVE_CLOSURE,  SEQ_TO_ARRAY 
commsnts:   Returns  a  tagged  set  consisting  o-f  the  right 
members  o-F  the  relation,  R. 

C LAMBDA  (R) 

(CONS  (QUOTE  Eset)   (MAPCAR  (CDR  R)  (QUOTE  CDRj) 

( REFLEX  I VE_TRANS I T I VE_CLOSURE 

******************************************************* 
args:       R  (Tagged  relation) 
calls:      UNION,  DOMAIN,  RANGE,  CONS,  MAPCAR, 

TRANS I T I VE_CLOSURE 
called  by:  SUPERSCRIPT 
binds:      TAG,  MEM,  X 
************************************************************ 
[LAMBDA  (R) 

(PROG  (TAG  MEM) 

(SETQ  TAG  (CAR  R) ) 

CSETQ  MEM  (UNION  (CDR  (DOMAIN  R) )   (CDR  (RANGE  Rj 

(RETURN  (CONS  TAG 

(UNION  CMAPCAR  MEM  (QUOTE  (LAMBDA  (X)   (CONS  X  X: 
(CDR  (TRANSITIVE  CLOSURE  Rj) 
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( RELAT I VE_PRODUCT 

************************************************************ 
args:       TBLl ,  TBL2  (Untagged  relations) 

calls:      APPEND,  MAPCAR ,  SELECT_ALL ,  CONS,  RELATI VE_PRODUCT 
called  by:  BIF_APPLY,  RELATIVE_PRODUCT,  TRANS ITIVE_CLOSURE 
binds:      X 

CDiTiments:   Returns  an  untagged  table  which  takes  the  right 
member  of  each  element  in  TBLl  and  relates  it 
to  the  set  of  all  right  members  it  is  related 
to  in  TBL2. 
************************************************************ 
CLANBDA  (TBLl  TBL2) 
(CGND 

( (NULL  TBLl)  NIL) 

(T  (APPEND  C MAPCAR  (CDR  (SELECT_ALL 

(CDAR  TBLl)  TBL2) ) 
(QUOTE  (LAMBDA  (X) 

(CONS  (CAAR  TBLl)  Xj 
(RELATIVE_PRODUCT  (CDR  TBLl)  TBL2:) 

( REPE AT_CGMP03 I T I ON 

************************************************************ 

args:       FNC  (RPL  function,  evaluated  form) 

P    (A  positive  integer) 
calls:      CONS,  LIST,  FNC_B0DY 
called  by:  SUPERSCRIPT 
binds:      SE 

comments:   A  special  case  of  the  "sup"  command.   Given  a 
function,  FNC,  and  the  number  of  times,  P,  FNC 
is  to  be  composed  with  itself,  returns  a 
closure  which  represents  the  resulting  function 
************************************************************ 
ilLAMBDA  (FNC  P) 
(PROG  (SE) 

(SETQ  SE  (CONS  (CONS  (QUOTE  f)  FNC) 

(CADDDR  FNC) ) ) 
(RETURN  (LIST  (QUOTE  closure) 
(QUOTE  K) 
(FNC  BODY  P)  SED) 


(REQUAL 

***********************************************************- 

args:        X,  Y  (Anything) 

calls:      MEMBER,  TYPE,  DO_SUBSET ,  TF ,  EQUAL 

called  by:  BIF_APPLY 
************************** *********************************i 

C LAMBDA  (X  Y) 
( COND 

CCAND  (MEMBER  (TYPE  X)  (QUOTE  (Eset  Erel ) ) ) 
(MEMBER  (TYPE  Y)  (QUOTE  (Eset  Erel : 
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(COND 

((AND  (EQ  (DO_SUBSET 
(EQ  (DO_SUBSET 
(QUOTE  true) ) 
(T  (QUOTE  -False: 
(T  (TF  (EQUAL  X  YD) 


(CDR 
(CDR 


X) 
Y) 


(CDR 
(CDR 


Y)  ) 
X)  ) 


(QUOTE 
(QUOTE 


true) ) 
true) ) ) 


(REVERSE_ARRAY 

args:       LST  (Tagged  relation) 

calls:       SORT,  DOMAIN,  PLUS,  REVERSE,  CONS,  MAPCAR 

DIFFERENCE,  LESSP 
called  by:  BIF_APPLY 
binds:      TAG,  DOM,  K,  X 
comments:   Given  an  array,  LST,  returns  3.n    a.rra.y    wit 

values  in  reverse  order. 

C LAMBDA  (LST) 

(PROG  (TAG  DOM  K) 

(SETQ  TAG  (CAR  LST) ) 

(SETQ  DOM  (SORT  (CDR  (DOMAIN  LST) ) 
(SETQ  K  (PLUS  (CAR  (REVERSE  DOM) ) 
(RETURN  (CONS  TAG 

(REVERSE  (MAPCAR  (CDR  LST) 

(QUOTE  (LAMBDA  (X)   (CONS  (DIFFERENC 

(CDR  X]) 


■M- •*■  +  **  * 


me 


(QUOTE  LE 
(CAR  DQM) ) 


*■*■**■*-* 


SSP) ) ) 


K  (CAR  X; ) 


(RNOT 

args:       B  (LISP  boolean) 
called  by:  BIF_APPLY 
comments:   RPL  negation 

**********  ***************************#  +  ****-M-*********-*^ 

C LAMBDA  (B) 
(COND 

((EQ  B  (QUOTE  true))   (QUOTE  false)) 
(T  (QUOTE  true:) 


■^**-** 
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(RPL_REPEAT 

ar gs:       EXP,  ER 

calls:      ERROR_HANDLER,  EV ,  TYPE,  RP APPLY 

called  by:  EV_SPECIAL_CASES 

binds:      F,  P,  X,  RESULT 

uses  -free:  ERRORCODE 

comments:   Given  an  expression  o-F  the  form: 
"repeat  (F  X)  until_not  P" 
created  by  the  "iter"  operation,  continues  to 
apply  F  to  X  until  the  predicate  P  is  true. 

CLAMBDA  (EXP  ER) 

(PROG  (F  P  X  RESULT) 

(SETS  F  (EV  (CAADR  EXP)  ER) ) 

(SETG  P  (EV  (CAADDR  (CDR  EXP))  ER) ) 

(SETQ  X  (EV  (QUOTE  ?k )  ER) ) 

( cor4D 

(CNOT  (AND  (EQ  ERRORCODE  (QUOTE  ERRQRFREE) ) 
(EQ  (TYPE  F)  (QUOTE  closure)) 
(EQ  (TYPE  P)  (QUOTE  closure] 
(ERROR_HANDLER  (QUOTE  EXP_FUNC) 

(QUOTE  (boolean  predicate  missing  or 

bad  function  definition  in  iter))) 
(GO  EXIT) ) ) 
(SETQ  RESULT  (RPAPPLY  F  X)) 
LOOP(COND 

( (EQ  (RPAPPLY  P  RESULT)  (QUOTE  true)) 
(SETQ  RESULT  (RPAPPLY  F  RESULT) ) 
(GO  LOOP) ) ) 
(RETURN  RESULT) 
EXIT!) 

(SEL 

args:       TBL  (Tagged  relation) 


TGT  (Anything) 


calls:      SASSQC,  ERROR_HANDLER ,  LIST 
called  by:  BIF_APPLY,  CONSTRUCTION 
binds:      X 

comments:   Returns  the  right  member  of  the  first 
occurrence  of  X  as  a  left  member. 

C LAMBDA  (TBL  TGT) 
I.  r  nuo  ':  A  > 

(SETQ  X  (SASSOC  TGT  (CDR  TBL))) 
(RETURN  (CDND 

( ( EQ  X  N I L )   ( ERROR_HANDLER  ( QUOTE  UBTE ) 
(LIST  TGT  (QUOTE  (not  found  in)) 
TBL) ) ) 

(T  (CDR  x:) 
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(SEQ_TO_ ARRAY 

************************************************************ 
args:       SEQ    (Tagged  relation) 

INDEX  (A  positive  integer) 
calls:      LDIFFERENCE,  DOMAIN,  RANGE,  LIST,  CONS,  LOOKUP, 

REVERSE,  PLUS 
called  by:  BIF_APPLY 
binds:      FIRST,  ARRAY 
comments:   Converts  a  sequence  to  an  a.rr-ay    indexed  from 

INDEX. 

CLAMBDA  (SEQ  INDEX) 
(PROG  (FIRST  ARRAY) 

CSETQ  FIRST  (CAR  (LDIFFERENCE  (DOMAIN  SEQ) 

(RANGE  SEQ: 
(SETQ  ARRAY  (LIST  (CONS  INDEX  FIRST) ) ) 
L00P(SETQ  FIRST  (LOOKUP  FIRST  (CDR  SEQ))) 
(COND 
C (EQ  FIRST  NIL) 

(RETURN  (CONS  (QUOTE  Erel )  (REVERSE  ARRAYl 
(T  (SETQ  INDEX  (PLUS  1  INDEX)) 

(SETQ  ARRAY  (CONS  (CONS  INDEX  FIRST)  ARRAY) ) 

(GO  loop:) 

(SUPERSCRIPT 

args:       OPND  (Tagged  relation  or  RPL  function) 
PWR   (+,  **,  or  a  positive  integer) 

calls:      EQUAL,  NUMBERP,  GREATERP ,  TYPE, 

REFLEX  I VE_TRANS I T I VE_CLOSURE ,  CONVERSE , 
TRANS I T I VE_CLOSURE ,  REPEAT_COMPOS I T I ON , 
ERROR_HANDLER 

called  by:  BIF_APPLY 

uses  free:  I EXP 

ccfniTients:        Handles    all    cases    of    the    operator    "sup". 

CLAMBDA  (OPND  PWR) 
(COND 

(  ( AND  ( EQUAL  PWR  ( QUOTE  ( c 1 osur  e  + )  ) ) 
(EQ  (TYPE  OPND)  (QUOTE  Erel))) 
(TRANSITIVE_CLOSURE  OPND) ) 
((AND  (EQUAL  PWR  (QUOTE  (closure  star))) 
(EQ  (TYPE  OPND)   (QUOTE  Erel))) 
(REFLEXIVE_TRANSITIVE_CLOSURE  OPND) ) 
((AND  (NUMBERP  PWR)   (EQ  PWR  -1) 

(EQ  (TYPE  OPND)   (QUOTE  Erel))) 
( CONVERSE  OPND ) ) 
( ( AND  ( NUMBERP  PWR )   ( GREATERP  PWR  0 ) 

(EQ  (TYPE  OPND)   (QUOTE  closure))) 
(REPEAT_COMPOSITION  OPND  PWR)) 
(T  (ERROR  HANDLER  (QUOTE  BAD  SYNTAX)  lEXPD) 
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(TAIL 

************************************************************ 
args:       X  (An  elementary  pair) 
calls:      ERROR_HANDLER 
called  by:  BIF_APPLY 
******************************************************* 
C LAMBDA  (X) 
( COND 

((AND  (LISTP  X)  (NOT  (NULL  X)))   (CDR  X)) 
(T  (ERROR_HANDLER  (QUOTE  EXP_PAIR)  XI) 

( TRANS I T I VE_CLOSURE 
************************************************************ 

args:       R  (Tagged  relation) 

calls:      CONS,  RELATIVE_PRODUCT,  UNION 

called  by:  REFLEX iyE_TRANSITIVE_CLOSURE,  SUPERSCRIPT 

binds:      TMP,  ANS 

•*-)*-M-********************************************************* 

C LAMBDA  (R) 

(PROG  (TMP  ANS) 

(SETQ  TMP  (CDR  R) ) 
(SETQ  ANS  (CDR  R) ) 
RPLOOP 

(COND 
( (NULL  TMP) 

(RETURN  (CONS  (CAR  R)  ANS))) 
(T  (SETQ  TMP  (RELATIVE_PRODUCT  TMP  (CDR  R) ) ) 
(SETQ  ANS  (UNION  ANS  TMP) ) 
(GO  RPLOOP :) 

(UNCURRY_EXT 
************************************************************ 

args:        TBL  (Tagged  relation) 

calls:      COERCE_TO_REL,  CONS,  APPEND,  MAPCAR , 
LIST_TO_REL,  LIST 

called  by:  BIF_APPLY 

binds:      TAG,  PTBL,  KEY,  SUBTBL,  UTBL,  X 

comments:   The  converse  of  CURRY_EXT. 
+***-jt*-*-*-j(-*i*-*-M-**-iii-************-j«-**************  ******  *********** 

[LAMBDA  (TBL) 

(PROG  (TAG  PTBL  KEY  SUBTBL  UTBL) 
(SETQ  TAG  (CAR  TBL) ) 
(SETQ  PTBL  (CDR  TBL)) 
LOOP [COND 

((NULL  PTBL)   (RETURN  (CONS  TAG  UTBL))) 
(T  (SETQ  KEY  (CAAR  PTBL) ) 

(SETQ  SUBTBL  (CDAR  PTBL)) 
(COND 

( (COERCE_TO_REL  SUBTBL) 

(SETQ  SUBTBL  (CDR  SUBTBL) ) 
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CSETQ  UTBL  (APPEND  UTBL 

(MAPCAR  SUBTBL  (QUOTE  (LAMBDA  (X) 
(CONS  CCQNS  (QUOTE  Erel ) 

(LIST_TO_REL  (LIST  KEY  (CAR  X3 
(CDR  X] 
(SETQ  PTBL  (CDR  PTBL) ) 

(GO  loop: 


exit:) 


(ALL_PAIRS 

args:       S  (Untagged  set) 
calls:      MEMB,  ALL_PAIRS 

called  by:  EV_SPECIAL_CASES,  C0ERCE_T0_REL,  ALL_PAIRS 
comments:   A  boolean  utility  -Function  which  determines  if 
all  the  elements  o-F  S  are    elementary  pairs. 

C LAMBDA  (S) 
(COND 

( (NULL  S)  T) 

(CAND  (LISTP  (CAR  S) ) 

(NOT  (MEMB  (CAAR  S) 

(QUOTE  (Eset  Erel  closure: 
(ALL  PAIRS  (CDR  S:) 


(BINARY_LIST 

args:       REL  (Tagged  relation) 
calls:      COERCE_TO_REL,  ERROR_HANDLER ,  LIST 
called  by:  CURRY_EXT 

comments:   A  boolean  utility  -function  which  verifies  that 
REL  is  art    RPL  binary  list. 

: LAMBDA  (REL) 
(COND 

( (COERCE_TO_REL  REL) 
( COND 

( ( AND  ( EQ  ( CAADR  REL )  1 ) 

(EQ  (CAADDR  REL)  2))  T) 
(T  (ERROR_HANDLER  (QUOTE  BAD_ARG) 

(LIST  REL  (QUOTE  (not  a  binary  list:) 
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(COERCE_TD_REL 

args:       S  (Tagged  relation) 

calls:      ALL_PAIRS,  TYPE,  ERROR_HANDLER 

called  by:  ARRAY_REDUCTIGN,  Ur4CURRY_EXT ,  BINARY_LIST, 

BIF_APPLY 
binds:      STYPE 

comments:   A  utility  -Function  which  changes  the  tags  on  a 
relation  i -F  S  is  a  set  and  is  equivalent  to  a 
relation. 
************************************************************* 
C LAMBDA  (S) 

(PROG  (STYPE) 

(SETQ  STYPE  (TYPE  S) ) 
(RETURN  (COND 

((EQ  STYPE  (QUOTE  Erel ) ) ) 
((AND  (ED  STYPE  (QUOTE  Eset)) 
(ALL_PAIRS  (CDR  S) ) )  S) 
(T  (ERROR  HANDLER  (QUOTE  EXP  RED  SI) 


(CURRY_ELEr-1ENT 

args:       KEY  (Anything) 

TBL  (Untagged  relation) 
calls:      CONS,  REVERSE,  MAPCAR,  LOOKUP 
called  by:  CURRY_EXT 
binds:      X 
comments:   A  auxiliary  function  to  CURRY_EXT,  which  -forms 

the  curried  element,  given  the  KEY  and  the  un- 

curried  table,  TBL. 

: LAMBDA  (KEY  TBL) 

(CONS  KEY  (CONS  (QUOTE  Erel) 

(REVERSE  (MAPCAR  TBL  (QUOTE  (LAMBDA  (X) 
(CONS  (LOOKUP  2  (CAR  X))  (CDR  XI) 
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(DISPLAY_ENV 

args:       FNC  (An  identifier  or  nothing) 

calls:      SPACES,  WRITE,  TERPRI ,  GET_ENV 

called  by:  DISPLAY 

binds:      ENV 

uses  -free:  USERDEFS 

comments:   Executes  the  "env"  operator.   Displays  the 

entire  environment  if  no  argument  is  given  or 
the  environment  associated  with  the  identifier, 
FNC.   The  environment  is  displayed  in 
definitional  form. 

C LAMBDA  (FNC) 
(PROG  (ENV) 

(SETQ  ENV  (GET_ENV  USERDEFS  FNC) ) 
LOOP(COND 

( (NULL  ENV) 
(SPACES  1) 

(WRITE  (QUOTE  (System  Defined  Functions))) 
(TERPRI) ) 
(T  (SPACES  1) 

(WRITE  (CDAR  ENV) ) 

(TERPRI) 

(SETQ  ENV  (CDR  ENV) ) 

(GO  loop:) 


(GET_ENV 

args:       L,  FNAME 
calls:      MAPCAR 
called  by:  DI3PLAY_ENV 
binds:      ENV,  X 

c ommen t s :   An  auxiliary  function  to  D I SPL A Y_EN V  wh i  c h 
returns  only  that  portions  of  L  (USERDEFS) 
which  s.rB    in  the  scope  of  FNAME  =. 
*-****  **********-s-****************-?r**  *********** 
r LAMBDA  (L  FNAME) 
(PRGG  (ENV) 
(COND 
( (NULL  FNAME)   (RETURN  L) ) 
(T  (SETQ  ENV  L) 

(MAPCAR  L  (QUOTE  (LAMBDA  (X) 
(COND 

( ( EQ  ( CAR  X )  FNAME )   ( RETURN  ENV ) ) 
(T  (SETQ  ENV  (CDR  ENV]) 
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(LIST_TO_REL 

************************************************************ 
args:       D  (Untagged  LISP  list) 
calls:      GREATERP,  PLUS,  LENGTH,  DIFFERENCE,  CONS, 

MAP2CAR 
called  by:  EVSEQ,  BIF_APPLY,  UNCURRY_EXT 
binds:      R,  C 

comments:   Returns  an  untagged  relation  which  represents 
the  appropiate  list,  D. 
************************************************************ 
C LAMBDA  (D) 

(PROG  (R  C)  • 

(SETQ  R  NIL) 

(SETQ  C  (PLUS  (LENGTH  D)  1)) 
LOOP  (SETQ  C  (DIFFERENCE  CD) 
(COND 
( (GREATERP  C  0) 

(SETQ  R  (CONS  C  R) ) 
(GO  LOOP) ) 
(T  R)  ) 
(RETURN  (MAP2CAR  R  D  (QUOTE  CQNSD) 


(LOOKUP 

args:       TGT  (Anything) 

TBL  (Untagged  relation) 
calls:      SASSOC 
called  by:  DEF_BINDING,  DISPLAY,  ERROR_HANDLER,  EV , 

CURRY_EXT,  SEQ_TO_ARRAY,  CURRY_ELEMENT 
binds:      X 
comments:   Returns  the  right  member  a-f    TBL  given  the  left 

member,  TGT,  i -f  TGT  is  -Found,  else  returns  NIL. 
************************************************************ 
C LAMBDA  (TGT  TBL) 
( PROG  ( X ) 


(SETQ  X 

(SASSOC  TGT  TBL) ) 

(RETURN 

( COND 

( (EQ  X  NIL)  NIL) 

(T  (CDR  x:) 

*->  -I  -^ 


(MAKE_UNIQUE 

************************************************************ 
args:        INPUT  (Untagged  set  ar    relation) 

RESULT,  ENV 
calls:      MEMBER,  REVERSE,  EV,  MAKE_UNIDUE,  CONS 
called  by:  EV_SPECI AL_CASES,  BIF_APPLY,  MAKE_UNIQUE 
coinments:   Eliminates  redundant  elements  -From  INPUT  and 
returns  RESULT. 
************************************************************ 

C LAMBDA  (INPUT  RESULT  ENV) 
(COND 

( (NULL  INPUT)   (REVERSE  RESULT) ) 
(T  (COND 

((MEMBER  (EV  (CAR  INPUT)  ENV)  RESULT) 

(MAKE_UNIQUE  (CDR  INPUT)  RESULT  ENV)) 
(T  (SETQ  RESULT  (CONS  (EV  (CAR  INPUT)  ENV) 

RESULT) ) 
(MAKE  UNIQUE  (CDR  INPUT)  RESULT  ENV 3) 


(NUMERIC_SET 

************************************************************ 
args:        SET  (Untagged  set) 
calls:      NUMBERP,  MAPCAR 

called  by:  BIF_APPLY,  ARRAY_CONCATENATION ,  MAX_SET,  MIN_SET 
binds:      X 

comments:   A  boolean  utility  function  which  determines  if 
all  members  of  SET  Are    numeric. 
************************************************************ 
[LAMBDA  (SET) 
(PROG  NIL 

C MAPCAR  SET  (QUOTE  (LAMBDA  (X) 

(COND 

( (NOT  (NUMBERP  X) ) 

(GO  exit: 

(RETURN  T) 
EXIT (RETURN  NIL]) 
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(POSIT 

args:       L       (Any  LISP  list) 

TARGET  (Anything) 
calls:      EQUAL,  SET,  PLUS 
called  by:  EXECUTE 
binds:      N 
comments:   A  utility  -function  used  to  -find  the  position  of 

the  "=="  symbol  in  an  RPL  command. 

C LAMBDA  (L  TARGET) 
(PROG  (N) 

(SET  (QUOTE  N)  0) 
LOOP(COND 

( (NULL  L)  (RETURN  0) ) 
((EQUAL  TARGET  (CAR  L) ) 

(RETURN  (PLUS  N  1) ) ) 
(T  (SET  (QUOTE  N)   (PLUS  N  1)) 
(SET  (QUOTE  L)  (CDR  L)  ) 
(GO  LOOP]) 


(PRINT_LIST 

args:       S  (Any  LISP  list) 

calls:       ATOM,  STRINGP,  MEMB,  SHOW_ATOM ,  PRINT_LIST 

called  by:  ERROR_HANDLER,  SHOW_ATOM,  PRINT_LIST 

comments:   An  output  utility  to  display  RPL  results  which 

are    in  a  LISP  list  -form  in  a  more  readable 

format. 

E LAMBDA  (S) 
( COND 

( (NULL  S)  NIL) 
(COR  (ATOM  S) 

(STRINGP  S) 

<EQ  (CAR  S)  (QUOTE  closure)) 
(MEMB  (CAR  S)   (QUOTE  (Eset  Erel 3 
(SHOW_ATOM  S) ) 
(T  (SHOUJ_ATaM  (CAR  S)) 
(PRINT  LIST  (CDR  SI) 


(READCMD 

calls:       WAITFORINPUT,  READLINE 
called  by:  RPL 

L LAMBDA  NIL  (WAITFORINPUT)   (READLINE:) 
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(READTERM 

calls:      WAITFORINPUT,  READLINE 
called  by:  SET_USER_ENV,  EXIT 

C LAMBDA  NIL  (WAITFORINPUT)   (CAR  ( READLINE 3) 


(READ_USER_DEFS 

*********************************************************** 
args:       FNAliE  (Unix  -filename) 
calls:      WRITE,  INFILE,  EXECUTE,  TERPRI ,  CLOSEALL , 

INFILEP,  READ 
called  by:  SET_USER_ENV  • 
binds:       INPUT,  DEFIN 
uses  -free:  ERRQRCODE 
comments:   A  utility  -function  which  reads  a  previous  RPL 

session's  commands  -from  FNAME  into  the  current 

RPL  session. 

C LAMBDA  (FNAME) 

(PROG  (INPUT  DEFIN) 

(SETQ  INPUT  (INFILEP  FNAME)) 
(COND 
( (NULL  INPUT) 

(WRITE  (QUOTE  (-file  not  found))) 
(GO  EXIT) ) ) 
(INFILE  INPUT) 

(WRITE  (QUOTE  (Loading ))) 

(SETQ  DEFIN  (READ  INPUT) ) 
LOOP (COND 

((EQ  DEFIN  (QUOTE  EOF)) 

(WRITE  (QUOTE  (Session  loaded))) 
(60  EXIT) ) 
(T  (SETQ  ERRORCODE  (QUOTE  ERRORFREE) ) 
(EXECUTE  DEFIN) 
(SETQ  DEFIN  (READ  INPUT)) 
(GO  LOOP) ) ) 
EXIT (TERPRI) 

(CLOSEALL  NIL]) 
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(SAVEF 

************************************************************ 
ar gs:       FNAME  (Unix  -f  i  1  ename) 

DEFS   (A  LISP  list  of  -Function  names) 
VARS   (A  LISP  list  o-f  variable  names) 
calls:      SET,  PACK,  LIST,  MAKEFILE 
uses  -Free:  FFNS,  FCOMS 
comments:   A  utility  function  used  to  write  all  or  a 

portion  of  the  LISP  functions,  and  variables  in 
the  current  LISP  environment  to  a  file.   Used 
to  create  the  RPL-INT  file.   Also  used  to 
convert  LISP  files  not  created  in  InterLisp  to 
the  InterLisp  input  format. 
************************************************************ 
-C LAMBDA  (FNAME  DEFS  VARS) 

CSETQ  FCOMS  (PACK  (LIST  FNAME  (QUOTE  COMS: 

CSETQ  FFNS  (PACK  (LIST  FNAME  (QUOTE  FNSD 

(SET  FFNS  DEFS) 

(SET  FCOMS  (LIST  (LIST  (QUOTE  FNS)   (QUOTE  *)  FFNS) 

(LIST  (QUOTE  VARS)  VARS))) 
(MAKEFILE  FNAME 3) 


(SELECT_ALL 

*4*.-S.^-<t***************************************************-ft-*-*.* 

args:       TGT  (Anything) 

TBL  (Untagged  relation) 
calls:      MAPCAR,  CONS,  REVERSE 
called  by:  BIF_APPLY,  RELATI VE_PRODUCT 
binds:      SET,  X 
comments:   Returns  an  untagged  set  of  all  the  right 

members  associated  with  the  TGT  in  TBL. 
************************************************************ 

C LAMBDA  (TGT  TBL) 
(PROG  (SET) 

(SETQ  SET  NIL) 

C MAPCAR  TBL  (QUOTE  (LAMBDA  (X) 
(COND 

( (EQ  (CAR  X)  TGT) 

(SETQ  SET  (CONS  (CDR  X)  SET 3 
(RETURN  (CONS  (QUOTE  Eset)   (REVERSE  SETD) 
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(SEQ_TO_REL 

args:       S  (Untagged  LISP  list) 

calls:      LEQ,  LENGTH,  CONS,  SEQ_TO_REL 

called  by:  EVSEQ,  BIF_APPLY,  SEQ_TO_REL 

comments:   Returns  an  untagged  relation  which  is  the 

result  o-f  converting  the  RPL  input  -form  tor  a 
sequence  to  its  internal  representation. 

C LAMBDA  (S) 
(COND 

((LEQ  (LENGTH  S)  1)  NIL) 
(T  (CONS  (CONS  (CAR  S)  (CADR  S) ) 
(SEQ_TO_REL- (CDR  SD) 

(SHDW_ATOM 

args:        X  (Any  LISP  atom) 

calls:       ATOM,  STRINGP,  MEMB ,  PRINl ,  PRINT_LIST,  LENGTH, 

CONS,  LIST,  SPACES 
called  by:  DISPLAY,  SHOW_ENV,  PRINT_LIST 
comments:   An  auxiliary  function  -for  output  o-f  RPL  atoms. 

C LAMBDA  (X) 
(SPACES  1) 
CCOND 

( (ATOM  X)  (PRINl  X) ) 
( (STRINGP  X)   (PRINl  X) ) 
C(MEMB  (CAR  X)   (QUOTE  (Eset  Erel ) ) ) 
(COND 

( (EQ  (LENGTH  X)  1)  (PRINl  (QUOTE  empty))) 
(  (EQ  (CAR  X)   (QUOTE  Eset))  (PRINl  (QUOTE  "/.()) 
(PRINT_LIST  (CONS  (QUOTE  set)  (CDR  X))) 
(PRINl  (QUOTE  '/.)  )  )  ) 
(T  (PRINl  (QUOTE  7.  ( )  ) 

(PRINT_LIST  (CONS  (QUOTE  rel )   (CDR  X))) 
(PRINl  (QUOTE  v.)  1 
H (EQ  (CAR  X)  (QUOTE  closure)) 
(COND 

I (EQ  (LENGTH  X)  4) 

(PRINl  (LIST  (CAR  X)   (CADR  X)   (CADDR  XD 

(T  (PRINl  x: 

(T  (PRINl  (QUOTE  VA)  ) 
(PRINT_LIST  X) 
(PRINl  (QUOTE  ■/.)  1 
(SPACES  i:) 
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args: 

calls: 

called 

by: 

binds: 

uses  -f 

ree: 

commen 

ts: 

(SHOW_ENV 
************************************************************** 

ENV 

MEMB,  LEQ,  WRITE,  SHOW_ATOM,  PRINT,  TERPRI , 

LENGTH,  LIST,  SHQW.ENV 

SHOW_ENV 

X 

OPNAMES 

First  implementation  for  the  "env"  command. 

Shows  the  evaluated  -form  o-F  the  environment. 

Not  currently  used,  le-ft  i-f  wanted  -For  -future. 

L LAMBDA  (ENV) 
(PROG  (X) 

(SETQ  X  (CAR  ENV) ) 
(RETURN  (CQND 

((MEMB  (CAR  X)  OPNAMES) 

(WRITE  (QUOTE  (System  De-fined  Functions))) 
(TERPRI) ) 
(T  CCOND 

( (LEQ  (LENGTH  X)  4) 
(SHOW_ATOM  X) 
(TERPRI) ) 
(T  (COND 

C (AND  (EQ  (CADR  X) 

(QUOTE  closure) ) 
(EQ  (LENGTH  X)  5) ) 
(PRINT  (LIST  (CAR  X) 
(CADR  X) 
(CADDR  X) 
(CADDDR  X] 
(T  (SHGW_ATOM  a) 
(TERPRI : 
(SHOW  ENV  (CDR  ENVD) 


(TF 

args:        B  (LISP  boolean) 

called  by:  BIF_APPLY,  REQUAL 

comments:   Converts  LISP  booleans  to  RPL  boolean  format. 

***********if***********-*-**********^********+*****  ******* 

[LAMBDA  (B) 
( COND 

( (EQ  B  NIL)   (QUOTE  false)) 
(T  (QUOTE  true!) 
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(TYPE 

************************************************************ 
args:       X  (Anything) 
calls:      ATOM,  STRINGP 

called  by:  DISPLAY,  EV_SPECI AL_CASES ,  INFIXOP,  PREFIXGP, 
BIF_APPLY,  MEM,  REQUAL,  RPL_REPEAT , 
SUPERSCRIPT,  COERCE_TO_REL 
comments:   A  utility  function  used  to  trap  illegal  calls 
to  the  LISP  -functions,  CAR  and  CDR.   Returns 
the  -First  element  i-f  X  is  a  list. 
************************************************************ 
[LAMBDA  (X) 
(COND 

((OR  (ATOM  X)  (STRINGP  X))  (OUOTE  atom)) 
(T  (CAR  x:) 

( UJR I TE 

************************************************************ 
args:       L  (LISP  list) 
calls:      PRIN2,  MAPCAR,  SPACES 

called  by:  RPL,  SET_USER_ENV ,  DEF_BINDING,  ERROR_HANDLER , 
EXIT,  FILE_READ,  DISPLAY_ENV,  READ_USER_DEFS , 
SHQW_ENV 
binds:       X 

comments:   A  utility  -function  which  alters  LISP  output  to 
a  more  natural  -form  without  parentheses. 
************************************************************ 
C LAMBDA  (L) 

(MAPCAR  L  (QUOTE  (LAMBDA  (X)  (PRIN2  X)  (SPACES  11) 


************************************************************ 
args:       FNAME  (Unix  filename) 
calls:      OUTFILE,  MAPCAR,  CLOSEALL ,  OUTFILEP,  REVERSE, 

PRINT 
called  by:  EXIT 
binds:      OUTPUT,  DEFOUT ,  X 
uses  free:  USERDEFS 

comments:   A  utility  function  used  to  write  the  current 
RPL  session's  commands  to  a  file,  FNAME. 
************************************************************ 
[LAMBDA  (FNAME) 

(PROG  (OUTPUT  DEFOUT) 

(SETQ  OUTPUT  (OUTFILEP  FNAME)) 
(OUTFILE  OUTPUT) 

(SETQ  DEFOUT  (REVERSE  USERDEFS)) 
C MAPCAR  DEFOUT  (QUOTE  (LAMBDA  (X) 

(PRINT  (CDR  X) 
OUTPUT 1 
(PRINT  (QUOTE  EOF)  OUTPUT) 
(CLOSEALL  nil:) 
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APPENDIX  G  z    EXAMPLES  OF  RPL  PROGRAMS 

A.  INTRODUCTION 

The  purpose  of  this  appendix  is  to  illustrate  two 
example  RPL  programs  which  demonstrate  the  -Flexibility  and 
potential  power  o-f  the  language,  and  also  some  o-F  the  design 
issues  involved  in  the  implementation. 

B.  EXAMPLE  #1  -  PAYROLL 

Suppose  there  is  a  file  o-f  employee  records  which  is 
keyed  upon  a  unique  employee  number.  These  records  contain 
only  the  employee  name  afid  accumulated  number  o-f  hours 
worked  -for  payroll  purposes. 

In  RPL  this  file  can  be  defined  as  a  simple  relation 
which  relates  the  employee  number  to  the  employee  record. 
The  employee  record  is  just  another  relation  between  field 
names  and  their  associated  values.  This  file  will  be 
refsred  to  as   the  'OldMastsr'  file. 


T  —       _ 


ddition  to  the  'OldMaster'  file  an   'Updates'   file 


which  would  contain  only  an  employee  number  related  to  the 
number  of  hours  for  a  given  time  period  is  required.  Again, 
this  file  can  be  represented  by  a  simple  relation. 

What  is  desired  is  a  program  that  will  take  the 
'OldMaster'  and  'Updates'  files  and  produce  a  new  updated 
master  with  current  accumulated  hours. 
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In  essence,  the  values  o-f  the  'hours'  -field  in  the 
'Oldliaster  '  -file  need  to  be  increased  by  the  amount  of  hours 
in  the  'Updates'  -file.  A  -function  to  do  this  can  be 
developed  -from  built— in  RPL  operators  and  takes  advantage  c-f 
the  in-fiK  to  pre-fix  conversion  functional,  the  functionals 
which  fi;-;  one  of  the  two  normal  infix  operator  arguments, 
and  several  combining  functionals.  The  power  of  RPL  is  that 
this  complicated  sequential  process  of  many  steps  can  be 
combined  into  virtually  two  steps  using  RPL  constructs. 
Figure  G— 1  shows  a  RPL  program  that  would  accomplish  the 
task. 


F  ==  (file  "QldMaster")  (1) 

U   ==   (file   "Updates")  (2) 

H  ==  "hours"  (3) 

sumhrs  ==  ( (op  +)  o  ( (rsec  sel  H)   ! !  I) )             (4) 

u  ==  (  (F  #  U)  rp  (as  o  (dsec  H  ,)  o  sumhrs)))  (5) 

F'  ==  ( (u  #  F)  rp  (op  ; ) )  (6) 

val  F'  (7) 


NOTES: 

(1)  F       =  old  file 

(2)  U       =  update  file 

(3)  H       =Field  name  for  hours  worked 

(4)  sumhrs  =  Update   auKiliary  function  to  add  old  hours 

to  the  update  hours 

(5)  u       =  Updating  function 

(6)  F'      =  New  file 

(7)  Display  file  in  evaluated  form 

Figure  G-1  —  Payroll  Example 

Notice  how  the  'op'  functional  is  used  to  allow  infix 
operators  to  be  combined  without  any  arguments.  Likewise, 
'  1  sec  '   and   'rsec'  a.re       used  to   fix   the   left   or   right 


^'~>  1 


argument,  respectively.  All  operators  in  this  example  a.re 
explained  in  detail  in  Appendix  C. 

F,  U,  and  H  ars  all  just  data  de-finitions  to  initialize 
the  names.  'sumhrs'  is  just  an  auxiliary  -function  which 
per-Forms  the  addition  required  and  also  makes  the  program  a 
little  easier  to  read.  The  updating  -function,  u,  really 
creates  an  extensional  function  in  the  form  of  a  relation 
(table)  which  contains  the  updated  'hours'  field.  The  new 
file  is  created  when  an  ordered  union  (;)  is  performed 
between  the  i^ecords  of  the  update  table  produced  by  u  and 
the  original  file,  '01  disaster '.  The  ordered  union  replaces 
the  value  of  the  'hours'  field  in  the  original  file  with  the 
new  value  contained  in  the  update  table.  Normally,  the  new 
structure  would  be  saved  for  use  as  the  'DldMaster'  the  next 
time  an  update  would  be  scheduled,  but  the  program  in 
Figure  G-1  simply  displays  the  resulting  file  for  the  user 
to  review. 

This  example  demonstrates  the  complexity  of  the 
language  that  had  to  be  dealt  with  in  the  implementation, 
but  also  gives  one  a  feeling  for  the  abstraction, 
flexibility  and  power  that  can  be  obtained. 

C.   EXAMPLE  #2  -  DEVELOPMENT  OF  'xi' 

The  RPL  operator  'xi'  filters  a  sequence  given  a 
predicate  to  test  its  elements.  In  order  to  better 
illustrate   the  need  and  execution  process  of  this   operator 


the  -following  RPL  sequence  will  be  used: 

s  ==  (seq  34-2  67-12-4) 
This  is  represented  internally  as, 

(rel  (3  4)   (4  -2)  (-2  6)  (6  7)   (7  -1)   (-1  2)  (2 
and  graphically  as 


4) 


-1 


—  A 


Suppose,  the  user  wanted  to  eliminate  the  negative  nodes 
in  the  sequence.  The  normal  -filter  operation  is  not 
suitable  since  it  would  simply  test  both  the  le-ft  and  right 
member  o-f  each  pair  in  the  relation  and  eliminate  the  entire 
node  it  either  element  was  negative.  The  result  o-f 
per -forming  a  ncrmai  filter  on  s  would  produce: 

(rel  (3  4)   (6  7)  ) 
Graphically,  this  is: 


resulting  elements  of  the  sequence  a.rB 
disconnected  and  the  valid  element,  '2',  has  been 
erroneously  deleted.  A  solution  to  this  problem  would  have 
to  reconnect  the  disconnected  nodes  and  not  eliminate  valid 
ones  by  mistake.   Thus,  the  ' k i '  operator  is  justified. 

The  'kI'  operator  accomplishes  this  process  i 
three  steps.    First,  the  transitive  closure  of  the  sequt 
is    computed.     Second,    the    undesireable    nodes 


el imininated  and  third,   the  redundant  edges  are  eliminated, 
This  process  is  illustrated  graphically  on  the  sequence  s. 
(1)  Compute  (s  sup  +) : 


(2)  Eliminate  negative  nodes  using  restriction, 
5  restr  (rsec  >  0) : 


(3)  Eliminate   redundant  edges  using  mu,   a  relation  mini 
mization  operator  de-fined  as:  (R  \  (R  1  (R  sup  +)  )  : 

s  !  (s  sup  +)  : 


s  \  (s  !  (s  sup  +)  )  : 


3  4-     6  7     2 


224 


Thus,  the  de-finition  for  'xi'    -follows: 

p  xi  r  ==  (mu  ( (r  sup  +)  restr  p) 
The  major  implementation  problem  here  is  the  large 
amount  o-F  temporary  storage  required  to  hold  the  transitive 
closure  o-f  s.  The  use  o-f  LISP  as  an  implementation  language 
eliminated  this  concern  since  it  already  has  a  built-in 
storage  management  system. 
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